GUID / UUID 데이터베이스 키의 장단점

모든 데이터베이스 키가 GUID / UUID 값 이면 데이터베이스 간 항목 이동이 훨씬 쉬워 졌던 과거 많은 데이터베이스 시스템에서 작업했습니다 . 나는이 길을 몇 번이나 내려가는 것을 고려했지만, 특히 성능과 전화로 읽을 수없는 URL에 대해서는 약간의 불확실성이있다.

데이터베이스에서 GUID를 광범위하게 다루는 사람이 있습니까? 그렇게하면 어떤 이점이 있습니까? 그리고 가능한 함정은 무엇입니까?

장점 :

• 오프라인으로 생성 할 수 있습니다.
• int와 달리 복제를 사소하게 만듭니다. 실제로 어렵습니다.
• ORM은 보통 그들처럼
• 여러 응용 프로그램에서 고유합니다. 따라서 앱 (또한 guid)에서 CMS (guid)의 PK를 사용할 수 있으며 충돌하지 않을 것임을 알 수 있습니다.

단점 :

• 더 큰 공간 사용이지만 공간이 저렴합니다 (er)
• 삽입 주문을 받기 위해 ID로 주문할 수 없습니다.
• URL에서보기 흉하게 보일 수 있지만 실제로 WTF는 URL에 REAL DB 키를 넣고 있습니까? (이 점은 아래 의견에서 이의 제기되었습니다)
• 수동 디버깅은 어렵지만 그렇게 어렵지는 않습니다.

개인적으로, 나는 적당한 크기의 모든 시스템에서 대부분의 PK에 사용하지만, 모든 곳에서 복제 된 시스템에 대해 "훈련"되었으므로 우리는 그것을 갖도록했습니다. YMMV.

중복 데이터가 쓰레기라고 생각합니다.하지만 중복 데이터를 얻을 수는 있지만 그렇게합니다. 대체 키는 일반적으로 내가 작업 한 곳에서 찌그러집니다. 우리는 WordPress와 같은 시스템을 사용합니다 :

• 행의 고유 ID (GUID / 무엇이든) 사용자에게 보이지 않습니다.
• 공개 ID는 일부 필드에서 한 번만 생성됩니다 (예 : 제목-기사 제목으로 설정).

업데이트 : 그래서 이것은 많은 +1을 얻었고 GUID PK의 큰 단점을 지적해야한다고 생각했습니다. 클러스터형 인덱스.

GUID에 많은 레코드와 클러스터 된 인덱스가있는 경우 끝이 아닌 항목 목록 (임의의 지점)에서 임의의 위치에 삽입 할 때 삽입 성능이 빨라집니다 (빠릅니다).

따라서 삽입 성능이 필요한 경우 auto-inc INT를 사용하고 다른 사람과 공유하려는 경우 GUID를 생성하십시오 (예 : URL에서 사용자에게 표시).

@ 맷 셰퍼드 :

고객 테이블이 있다고 가정하십시오. 확실히 고객이 테이블에 두 번 이상 존재하지 않게하거나 영업 및 물류 부서 전체에서 많은 혼란이 발생합니다 (특히 고객에 대한 여러 행에 다른 정보가있는 경우).

따라서 고객을 고유하게 식별하는 고객 식별자가 있으며 고객이 식별자를 송장으로 알 수 있도록하여 고객과 고객 서비스 담당자가 통신해야 할 경우 공통 참조를 갖도록합니다. 중복 고객 레코드를 보장하지 않으려면 고객 식별자의 기본 키 또는 고객 식별자 열의 NOT NULL + UNIQUE 제약 조건을 통해 테이블에 고유성 제약 조건을 추가합니다.

다음으로, 어떤 이유로 (생각할 수없는) GUID 열을 customer 테이블에 추가하고 기본 키로 만들어야합니다. 고객 식별자 열이 고유성 보증없이 남겨진 경우 GUID는 항상 고유하므로 조직 전체에서 향후 문제가 발생할 수 있습니다.

"아키텍트"는 "아, 그러나 우리는 앱 계층에서 실제 고객 고유성 제약을 처리합니다 !" 라고 말할 수 있습니다 . 권리. 이러한 범용 프로그래밍 언어 및 특히 중간 계층 프레임 워크와 관련된 패션은 항상 변경되며 일반적으로 데이터베이스보다 오래 지속되지 않습니다. 그리고 현재 응용 프로그램을 거치지 않고 데이터베이스에 액세스해야 할 가능성이 매우 높습니다. == 문제입니다. (다행히도, 당신과 "건축가"는 오래 전에 없어 졌으므로 혼란을 제거 할 수는 없습니다.) 즉, 데이터베이스 (및 다른 계층에서도 시간).

다시 말해서, 테이블에 GUID 열을 추가해야 할 이유가있을 수 있지만 실제 (== GUID가 아닌) 정보 내에서 일관성을 유지하려는 야심을 줄이려는 유혹에 빠지지 마십시오 .

왜 아무도 성능에 대해 언급하지 않습니까? 여러 개의 조인이있을 때 모두이 불쾌한 GUID를 기반으로 성능이 바닥을 통과합니다. (

GUID가 "유니 파이어"로 사용되는 경우 나중에 GUID로 인해 많은 문제가 발생할 수 있으며, 중복 된 데이터가 테이블에 들어갈 수 있습니다. GUID를 사용하려면 다른 열에서 UNIQUE 제약 조건을 계속 유지하십시오.

주요 장점은 데이터베이스에 연결하지 않고도 고유 ID를 만들 수 있다는 것입니다. 또한 ID는 전 세계적으로 고유하므로 다른 데이터베이스의 데이터를 쉽게 결합 할 수 있습니다. 이것들은 작은 장점처럼 보이지만 과거에 많은 작업을 저축했습니다.

주요 단점은 약간 더 많은 스토리지가 필요하고 (현대 시스템에서는 문제가되지 않음) ID는 실제로 사람이 읽을 수있는 것이 아닙니다. 디버깅 할 때 문제가 될 수 있습니다.

인덱스 조각화와 같은 일부 성능 문제가 있습니다. 그러나 그것들은 쉽게 풀 수 있습니다 (지미 닐슨의 빗 길드 : http://www.informit.com/articles/article.aspx?p=25862 )

이 질문에 대한 두 가지 답변을 병합하여 수정

@Matt Sheppard 나는 다른 GUID를 가진 행을 기본 키로 복제 할 수 있음을 의미한다고 생각합니다. 이것은 GUID뿐만 아니라 모든 종류의 대리 키와 관련된 문제입니다. 그리고 그가 말했듯이 키가 아닌 열에 의미있는 고유 한 제약 조건을 추가하여 쉽게 해결할 수 있습니다. 대안은 자연 키를 사용하는 것이며 실제 문제가 있습니다.

해당 열을 클러스터형 인덱스로 사용하는 경우 GUIDS를 기본 키로 사용하는 경우 고려해야 할 또 다른 작은 문제는 비교적 일반적인 방법입니다. 어쨌든 순차적으로 시작되지 않는 guid의 특성으로 인해 insert에서 hit을 수행 할 것이므로 삽입 할 때 페이지 분할 등이 발생합니다. 시스템의 IO가 높을 경우 고려해야 할 사항 ...

기본 키 ID와 대 GUID

기본 키로서의 GUID 비용 (SQL Server 2000)

신화, GUID 및 자동 증분 (MySQL 5)

이것은 당신이 원하는 것입니다.

UID 전문가

• 모든 테이블, 모든 데이터베이스, 모든 서버에서 고유
• 다른 데이터베이스의 레코드를 쉽게 병합 할 수 있습니다
• 여러 서버에 데이터베이스를 쉽게 배포 할 수 있습니다
• 데이터베이스로 왕복하지 않고 어디에서나 ID를 생성 할 수 있습니다.
• 대부분의 복제 시나리오에는 GUID 열이 필요합니다.

GUID 단점

• 전통적인 4 바이트 인덱스 값보다 4 배나 더 큽니다. 주의하지 않으면 성능과 스토리지에 심각한 영향을 줄 수 있습니다.
• 번거롭게 디버깅하기 (여기서 userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• 생성 된 GUID는 최상의 성능 (예 : SQL 2005의 newsequentialid ())과 클러스터 된 인덱스를 사용할 수 있도록 부분적으로 순차적이어야합니다.

실제로 해결되지 않은 한 가지 방법이 있습니다. 즉 기본 키로 임의 (UUIDv4) ID를 사용하면 기본 키 인덱스 의 성능이 저하 됩니다. 테이블이 키 주위에 클러스터되어 있는지 여부에 관계없이 발생합니다.

RDBM은 일반적으로 기본 키의 고유성을 보장하고, 분기 요소가 큰 검색 트리 인 BTree라는 구조에서 키에 의한 조회를 보장합니다 (이진 검색 트리의 분기 계수는 2 임). 이제 순차 정수 ID는 삽입 이 트리의 한 쪽에서 만 발생하도록 하여 대부분의 리프 노드를 그대로 둡니다. 임의의 UUID를 추가하면 삽입이 인덱스 전체에서 리프 노드를 분할합니다.

마찬가지로 저장된 데이터가 대부분 일시적인 경우 가장 최근의 데이터에 액세스하여 가장 많은 데이터를 결합해야하는 경우가 종종 있습니다. 임의의 UUID를 사용하면 패턴이 이로 인한 이점을 얻지 못하고 더 많은 인덱스 행에 도달하므로 메모리에 더 많은 인덱스 페이지가 필요합니다. 순차 ID를 사용하면 가장 최신 데이터가 가장 많이 필요한 경우 핫 인덱스 페이지에 더 적은 RAM이 필요합니다.