Guid vs INT-기본 키로 어느 것이 더 낫습니까?

97

나는 이유를 사용하는 주위를 읽거나하지 존재 한 Guid과 int.

int작고 빠르며 기억하기 쉬우 며 시간 순서를 유지합니다. 그리고 Guid내가 찾은 유일한 장점은 독창적이라는 것입니다. 어떤 경우에 a Guid보다 낫고 int왜 그렇습니까?

내가 본 것에서 int, 많은 경우에 관계없는 수 제한을 제외하고는 결함이 없습니다.

왜 정확히 Guid만들어 졌습니까? 실제로 간단한 테이블의 기본 키 역할을하는 것 이외의 목적이 있다고 생각합니다. ( Guid무엇 을 위해 사용하는 실제 응용 프로그램의 예 입니까?)

_{SQL Server의 (Guid = UniqueIdentifier) 유형}

— BrunoLM
소스

1

기본 키가 아니라 대리 키, 즉 자연 키가 아닌 키 (실제 키는 실제 세계에서 사용하는 키)를 의미한다고 생각합니다 . 아마도 클러스터형 인덱스를 의미 할 것입니다.

— 언젠가

또한 (기본) KEY와 INDEX의 차이점을 기억하십시오.

— Allan S. Hansen

1

또한 SO에 대해 논의했다 : stackoverflow.com/questions/11033435/…

— 모든 거래의 존

2

" int많은 경우에 무관 횟수 제한, 제외 가능한 결함이 없다."실제로, GUID 대 INT의 컨텍스트 내에서, 서명, 32 비트의 상한 INT(A)의 상한은 체결 주어진 완전히 무관 , 64 비트 BIGINT는 거의 모든 용도를 훨씬 능가합니다 (하한선에서 번호 매기기를 시작하면 더 그렇습니다 INT.

— Solomon Rutzky

89

이것은 여기 와 여기 에 스택 오버플로 에서 요청되었습니다 .

Jeff의 게시물 은 GUID 사용의 장단점에 대해 많이 설명합니다.

GUID 전문가

모든 테이블, 모든 데이터베이스 및 모든 서버에서 고유

다른 데이터베이스의 레코드를 쉽게 병합 할 수 있습니다

여러 서버에 데이터베이스를 쉽게 배포 할 수 있습니다

데이터베이스로 왕복하지 않고 어디에서나 ID를 생성 할 수 있습니다.

대부분의 복제 시나리오에는 GUID 열이 필요합니다.

GUID 단점

전통적인 4 바이트 인덱스 값보다 4 배나 더 큽니다. 주의하지 않으면 성능과 스토리지에 심각한 영향을 줄 수 있습니다.

성가신 디버깅 ( where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')

생성 된 GUID는 최상의 성능 (예 : newsequentialid()SQL Server 2005+) 및 클러스터 된 인덱스 사용을 위해 부분적으로 순차적이어야 합니다.

성능이 확실하고 레코드를 복제하거나 병합하지 않으려는 경우을 사용 int하고 자동 증분 ( SQL Server의 ID 시드 )을 설정하십시오.

— 코더 호크
소스

20

GUID 방식의 또 다른 단점은 최종 사용자의 식별자로 사용할 수 없다는 것입니다. 당신은 정말로 사용자가 전화로 주문 "BAE7DF4-DDF-3RG-5TY3E3RF456AS10"에 문제가 있다고 말 하시겠습니까? :)

— Brann

3

순차 guid를 사용하지 않고 기본 키가 클러스터 된 경우 (SQL Server 기본 설정) 모든 데이터 삽입이 테이블 전체에 무작위로 흩어져서 데이터가 크게 조각화됩니다. 이는 데이터가 일반적으로 연대순과 같은 일종의 순서로 삽입된다고 가정합니다.

— datagod

6

순차적 guid는 SQL 인스턴스가 다시 시작될 때까지만 순차적입니다. 그러면 루트 값이 생성되는 방식으로 인해 첫 번째 값이 이전 값보다 낮을 가능성이 높아 모든 종류의 문제가 다시 발생합니다.

— mrdenny

20

@Brann 이상적으로는 최종 사용자에게 PK 가치가 주어지지 않을 것입니다. 나는 그렇게하는 것이 다소 흔하다는 것을 알고 있으며, 내가 배우지 않기 전에 과거에 내가 한 일이다. 그러나 수행해서는 안되므로 GUID보다 INT를 선호하는 특별한 이유는 유효하지 않습니다.

— Solomon Rutzky

2

선택 @ChadKuehn UNIQUEIDENTIFIER이상 INT때문에 INT하는 아닌만큼 진정한 동안 상한을 가지고 무한한되고 이후 오히려 가난한 추론이다 실질적인 혜택을 누릴 수 있습니다. INT1이 아닌 하한 (2.14 십억)에서 시작 하여 유효 용량을 쉽게 두 배로 늘릴 수 있습니다 . 또는 45 억이 충분하지 않은 경우 BIGINT여전히 8 바이트로 시작합니다. GUID의 경우 16과 비교되며 이는 중요합니다.

— Solomon Rutzky

18

데이터를 외부 소스와 동기화하는 경우 지속적인 GUID가 훨씬 더 좋습니다. GUID를 사용하는 빠른 예는 고객에게 네트워크를 크롤링하고 특정 클래스의 자동 검색을 수행하고 찾은 레코드를 저장 한 다음 모든 고객 레코드를 중앙 데이터베이스에 통합하기 위해 보내는 도구입니다. 우리 끝에 다시. 정수를 사용하면 7,398 개의 "1"을 갖게되며 어느 "1"이 어떤 것인지 추적하기가 훨씬 더 어려워집니다.

— TML
소스

3

GUID는 외부 식별자로 확실히 우수하며, 클러스터되지 않은 인덱스를 "외부 키"로 유지하고 클러스터 된 인덱스와 외래 키 관계의 기초 인 "내부 키"로 int를 유지합니다. 무언가가 건축 경계를 넘어갈 것이라면 (예 : 다른 응용 프로그램과의 통신) 나는 섞을 수없는 것을 갖는 것에 감사합니다.

— Greg

15

나는 성공적으로 하이브리드 접근법을 사용했습니다. 테이블에는 자동 증분 기본 키 정수 id열과 guid열이 있습니다. 는 guid고유 전역 행을 식별하는 데 필요한과로 사용할 수 있습니다 id정렬 및 행의 인간의 식별 된 조회에 대해 사용할 수 있습니다.

— 리미 라벨
소스

3

id이미 인간이 행을 식별하기에 충분한 경우 GUID는 어떤 가치를 제공 합니까?

— Martin Smith

6

id는이 테이블의 행을 식별합니다. GUID (적어도 이론적으로는)는 알려진 유니버스의 모든 위치에서이 행을 식별합니다. 내 프로젝트에서 Android 모바일 각각은 로컬 SQLite 데이터베이스에 구조적으로 동일한 테이블 사본을 가지고 있습니다. 행과 해당 GUID는 각각 Android에서 생성됩니다. 그런 다음 Android가 백엔드 데이터베이스에 동기화되면 다른 Android 모바일에서 작성된 행과 충돌 할 염려없이 로컬 행이 백엔드 테이블에 기록됩니다.

— rmirabelle

2

@ MartinSmith 나는이 접근법을 직접 사용했으며 꽤 잘 작동합니다. GUID는 비 클러스터형 인덱스가있는 대체 키일 뿐이며 응용 프로그램에서 전달되지만 기본 테이블에만 상주합니다. 모든 관련 테이블은 INTPK 를 통해 관련됩니다 . 이 접근 방식이 두 세계의 최고라는 점을 감안할 때 훨씬 일반적이지 않은 것이 이상합니다. 대부분의 사람들은 앱이 글로벌 고유성 및 / 또는 이식성을 위해 GUID를 계속 사용하기 위해 PK가 GUID 일 필요는 없다는 것을 인식하지 않고 매우 절대적인 용어로 문제를 해결하는 것을 선호하는 것 같습니다.

— Solomon Rutzky

1

@ rmirabelle 나는이 접근법에 대해 생각하고 망설 였지만 대답은 저를 설득했습니다. 기본적으로 작업 항목에 대한 고유 식별자 (어디에서나 네트워크를 통해 올 수 있음)가 필요하지만 먼저 데이터베이스로 왕복하고 싶지는 않습니다. GUID는 이것에 대한 좋은 솔루션이지만 순차적 클러스터 키가 없으면 JOIN이 훨씬 느려질 것입니다.

— easuter

1

@easuter 본인은 PK가 관련된 두 FK의 합성이어야하는 다 대다 "브리지"테이블과 같이 ID 필드를 "단지"목적으로 추가하지 않을 것에 동의합니다. 그러나 여기서 ID 필드는 단순히 그것을위한 것이 아니기 때문에 절충이 아닙니다. 시스템이 효율적으로 작동하도록하는 것은 상당히 중요합니다 ;-). 그리고 귀하의 경우 GUID가 외부에서 생성되기 때문에 실제로는 GUID가 고유하더라도 보장 되지는 않습니다 . 그러나 데이터 무결성에 대한 책임은 GUID 대체 키와 ID가 : 귀하의 경우 PK를 할 수있을 정도로 이유

— 솔로몬 Rutzky

1

일부 모범 사례에서는 여전히 사용하려는 전체 값 집합에 적은 메모리를 사용하는 데이터 형식을 사용해야한다고 언급하고 있습니다. 예를 들어, 소규모 사업체에 다수의 고용주를 저장하기 위해 사용하고 100에 도달하지 않을 것이라면 int (smallint)조차도 bigint 값을 사용하도록 제안하지 않을 것입니다.

물론, 이것의 단점은 "확장성에 대해 말하십시오!"와 같습니다.

또한 이것이 완전히 관련이 없다는 것을 알고 있지만 이에 관한 또 다른 요인이 있습니다. 익히지 않을 때는 일반적으로 자동 생성되지 않은 기본 키를 사용하는 것이 좋습니다. 예를 들어, 운전자 정보를 저장하는 경우 "ID"에 대한 새로운 자동 생성 열을 생성하지 않아도 라이센스 번호 만 사용하십시오.

~~나는 이것이 분명하게 들린다는 것을 알고 있지만, 자주 잊혀지는 것을 본다.~~

맥락 : 답변의이 부분은 PK가 레코드의 고유 한 데이터 식별자가되기를 원하는 데이터 이론적 접근 방식에서 해결되었습니다. 대부분의 경우 우리는 이미 존재 할 때 생성하므로 이전 답변입니다.

그러나 이러한 데이터 포인트를 엄격하게 제어 할 수있는 경우는 거의 없으므로 수정 또는 조정이 필요할 수 있습니다. 기본 키로는 그렇게 할 수 없습니다 (물론 할 수는 있지만 고통 스럽습니다).

설명을 해주신 @VahiD에게 감사드립니다.

— 알파
소스

의미있는 기본 키를 사용하는 것은 전혀 권장되지 않습니다. 아래 시나리오를 고려하십시오. 누군가 잘못된 라이센스 번호를 입력했으며 3-4 테이블 에서이 ID를 외래 키로 사용했습니다.이 실수를 어떻게 해결합니까? 이 경우 라이센스 번호를 편집하는 것만으로는 충분하지 않습니다.

— VahiD

1

웃긴 : 나는 당신의 의견을 읽었으며 "물론 예"라고 생각했다가 다시 답을 읽고 "내가 그 말을 했습니까?"라고 생각 했습니까? 몇 년 동안 상황이 어떻게 변하는 지 재밌습니다. 나는 아마도 더 이론적 인 배경에서 왔을 것입니다. 그러나 당신이 그것을 엄격하게 통제하지 않으면 (드물게) 많은 이점을 제공하지 않습니다. 답변을 업데이트하겠습니다.

— Alpha

몇 년 동안 개발에 대한

— 찬성 투표

1

자동 증분 ID를 사용하면 비즈니스 활동에 대한 정보가 유출 될 수 있습니다. 상점을 운영하고 order_id있고 구매를 공개적으로 식별하는 데 사용하는 경우 누구나 간단한 산술로 월별 판매 수를 확인할 수 있습니다.

— 골로 팟
소스

0

GUID 생성 방법에 관한 또 다른 것. mrdenny는 newsequentialid ()를 사용하더라도 인스턴스를 다시 시작하면 새 값이 이전 처리에서 남은 "구멍"으로 시작된다고 올바르게 지적했습니다. "순차적"GUID에 영향을주는 또 다른 것은 네트워크 카드입니다. 올바르게 기억하면 NIC의 UID가 GUID 알고리즘의 일부로 사용됩니다. NIC를 교체하면 순차적 인 측면을 유지하기 위해 UID가 더 높은 가치를 보장하지 않습니다. 또한 여러 NIC가 알고리즘을 사용하여 값 할당에 어떤 영향을 줄 수 있는지 잘 모르겠습니다.

그냥 생각하고 올바르게 기억하고 싶습니다. 좋은 하루 되세요!

— bobo8734
소스

2

데이터베이스 관리자 bobo8734에 오신 것을 환영합니다. 이 의견에 대한 출처를 찾을 수 있습니까? 확실하지 않은 경우 독립형 답변보다 의견으로 답변하는 것이 좋습니다 (대리인이있을 때).

— LowlyDBA

-6

둘 다 사용

유지 관리가 쉽고 외래 키 관계로 사용하기 때문에 기본 키에 int / Bigint 를 사용하십시오 .

그러나 모든 행에 고유 한 열이 있도록 열을 GUID에 바인딩하십시오.

— 압둘 한난이자 즈
소스

2

이 제안에 대한 당신의 추론을 설명해도 아무도 해치지 않을 것입니다.

— Andriy M

특정 사례를 검색하는 경우 GUID는 36 자 길이로 읽기가 어렵습니다.

— Abdul Hannan Ijaz

1

좋아,하지만 정말 영업 이익은 모두 사용해야하는 이유를 설명하지 않습니다 int그리고 guid당신은 당신의 대답에 제안하는대로. 게다가, 나는 단지 나에게 당신의 제안을 설명하는 것에 대해 이야기하지 않았습니다 – 제 요점은 당신이 당신의 대답 을 업데이트 하고 싶을 수도 있다는 것 입니다. 그건 그렇고, 다른 응답자 가 이미 당신 과 같은 (더 많거나 적은) 것을 제안 했음을 알고 있습니까?

— Andriy M

그래, 난 똑같은 의미 .. 멋진 BTW :)

— 압둘 한난 Ijaz