DB 테이블의 Primary Key는 무엇이 최선인가?!

테이블 설계 중 테이블의 pk 값을 무엇으로 할것인가에 대한 논의가 있었다 이에 관련 자료를 찾던중 괜찮을 만한 글을 찾았다.
(아래 내용은 단순 번역글입니다.)

개요

임의의 데이터베이스 테이블을 생성하는 첫 번째 단계 중 하나는 상기 테이블에서 주어진 행을 고유하게 식별 할 데이터의 종류를 결정하는 것이다. 이를 Primary key 라고 합니다.

현대 데이터베이스에서 "thin air"로 고유 한 키(unique key)를 만들고 기존 데이터를 사용하지 않으려는 경우 (이 상황을 대리 키(surrogate key) 를 사용하는 것으로 알려짐 ) 일반적으로 허용되는 두 가지 옵션이 있다. 즉 정수(integer) 사용 또는 고유 식별자 (GUID).

두가지 모두 데이터베이스 자체 또는 다른 시스템에 의해 자동으로 생성 될 수 있습니다. 하지만 무엇이 더 좋을까? 정수와 GUID를 기본 키로 사용하는 장단점에 대해 논의하고 데이터베이스와 응용 프로그램에서 더 잘 작동하는 것을 발견 할 수 있는지 확인해 봅시다.

정수 사용

기본 키에 정수를 사용하는 것을 선호하는 기본 인수는 단순성 때문입니다. 결국, 그들은 단지 숫자입니다. 정수를 기본 키로 사용하는 테이블을 인쇄 한 경우 데이터를 읽고 이해하기 쉽습니다.

정수를 기본 키 유형으로 사용하는 경우 사용자가 특정 항목의 ID (원하는 항목 일 수도 있고 아닐 수도 있음)를 쉽게 추측 할 수 있습니다. 사용자가이 URL과 유사한 URL을 발견했다고 가정 해 봅시다.

/locations/5/hours

사용자가보고 싶은 위치의 ID가 120임을 이미 알고있는 경우 URL을 다음과 같이 변경하면됩니다.

/locations/120/hours

이 방법으로 사용자는 시스템에 대한 몇 가지 추가 지식을 얻을 수 있으며 어떤 정보가 어디에 존재하는지 예측할 수있게됩니다. 전반적으로, 그것은 우리의 응용 프로그램의 사용자 경험을 더 멋지게 만듭니다.

마지막으로 정수는 작습니다. 그들은 단지 4 바이트의 저장 공간만을 사용합니다. 즉, 정수를 기본 키 유형으로 사용할 때 일반적으로 인덱싱 및 쿼리와 같은 작업이 빨라집니다. 그러나 엄청난 응용 프로그램이 마련되어 있지 않으면 차이가 없을 것입니다.

즉, 다음 경우에 정수를 사용하십시오.

당신은 쉽게 이해할 수있는 ID를 원합니다.
최종 사용자가 URL을 "해킹 가능"하게하려고합니다.
매우 큰 응용 프로그램에서 성능에 대해 우려하고 있습니다.

GUID 사용

GUID는 Globally-Unique Identifier의 약자이며 다음과 같은 형식의 32 진수 문자로 구성됩니다.

65ac3d1d-f339-7aae-881a-acc6832ffe81

GUID는 Internet Engineering Task Force (IETF)에서 공식적으로 RFC 4122 로 정한 Universally-Unique Identifier 아이디어 의 특정 형식입니다 . GUID라는 용어와 형식은 원래 Microsoft에서 개발하여 사용했습니다.

GUID의 특징을 정의하는 것은 상대적으로 말하면 거대합니다 . 16 바이트의 저장 공간을 사용하는 반면 정수는 4 바이트만을 사용합니다. 그런데 왜 아무도 데이터 형식에서 큰 엔트로피 가 필요 합니까? 그 답을 발견하기 위해 수학을 해보 죠.

GUID에는 2 개의 128 개의 가능한 조합이 포함됩니다. 즉, 이 구조에서 3.4x10 개의 가능한 고유 값을 생성 할 수 있습니다. 서면 번호 는 대략 다음과 같습니다 .

34,028,236,692,093,846,346,337,460,743,177,000,000

엄청나게 큰 숫자입니다. 관점에서 이것을 넣으려면 이 블로그 에 따르면 어딘가에 지구의 해변에 5.6x10 21 그루 의 모래가 있습니다. 모든 사람이 반복없이 6.07x10^16 GUID 를 사용할 수 있습니다 . 엄청나게 큰 데이터 세트가 없으면 중복 GUID가 표시되지 않습니다.

동일한 GUID를 두 번 얻지 못하도록 사실상 보장되기 때문에 여러 소스에서 많은 데이터를 수집하는 것이 훨씬 쉬워집니다. GUID를 기본 키로 사용하는 데이터베이스의 데이터를 데이터베이스에 병합하는 경우 충돌이 발생할 가능성이 거의 없으므로 확인하지 않아도됩니다. GUID에 의해 호출 된 엔트로피 덕분에 개발자는 대다수 상황에서 충돌을 처리 할 필요가 없습니다.

그러나 GUID 가 너무 크기 때문에 충분히 큰 데이터 집합을 사용하면 이론적으로 성능이 저하 될 수 있습니다. 특히 인덱싱은 저장되는 데이터의 크기로 인해 어려움을 겪을 수 있습니다. 하지만 성능에 얼마나 영향을 미칠지 에 대한 의견은 다양 합니다.

GUID를 사용하는 또 다른 이유는 사용자가 쉽게 기억하지 못하기 때문에 Integers를 사용할 때 "해킹 가능" URL을 얻지 못한다는 것입니다. 시스템에 따라이 방법이 적합 할 수 있습니다.

즉, 다음과 같은 경우에 GUID를 사용하십시오.

데이터의 출처와 상관없이 데이터를 고유하게 식별하려고합니다.
차이가있는 소스의 데이터를 복제 GUID가 거의 또는 전혀없이 결합 할 수 있어야합니다.
ID를 기억할 필요가있는 사용자는 원하지 않거나 신경 쓰지 않아도됩니다.

Which is Better ?

언제나 그렇듯이 이런 종류의 결정은 당신이 구축하고있는 시스템의 종류에 달려 있습니다. 그러나 IMO 는 전역 고유성이 필요할 수 있는 매우 큰 분산 시스템을 사용하는 경우 정수를 기준으로 GUID를 선호 해야합니다.

GUID에 대한 성능 논쟁은 시간의 흐름과 기술의 향상으로 대체로 무효화되었습니다. 최신 시스템에서는 두 데이터 유형간에 성능 차이가 눈에 띄지 않습니다.

또한, 정수를 사용하는 것을 선호하는 "hackable"인수는 완전히 잘못되었습니다. 왜 사용자는 무엇을 기억해야합니까? 사용자가이 작업을 수행 할 수는 있지만 좋지는 않습니다.

이러한 두 가지 점에도 불구하고 복잡한 시스템이 없다면 GUID가 필요로하는 추가 복잡성을 호출 할 이유가 없습니다. 내 마음 속에서, 인수는 명확성과 보장 된 유일성에 이릅니다 . 최상의 코드는 코드가 아니므로 매일 정수의 단순성을 취할 것입니다.

출처

Integers vs GUIDs - The Great Primary Key Debate