테이블의 기본 키에 대한 모범 사례는 무엇입니까?


256

테이블을 디자인 할 때 고유 한 열을 갖는 습관을 개발하고 기본 키를 만듭니다. 이는 요구 사항에 따라 세 가지 방식으로 달성됩니다.

  1. 자동 증분되는 ID 정수 열입니다.
  2. 고유 식별자 (GUID)
  3. 행 식별자 열로 사용할 수있는 짧은 문자 (x) 또는 정수 (또는 기타 비교적 작은 숫자 유형) 열

숫자 3은 상당히 작은 조회, 주로 고유 한 정적 길이 문자열 코드 또는 1 년 또는 기타 숫자와 같은 숫자 값이있는 테이블을 읽는 데 사용됩니다.

대부분의 경우 다른 모든 테이블에는 자동 증분 정수 또는 고유 식별자 기본 키가 있습니다.

질문 :-)

최근에 일관된 행 식별자가없는 데이터베이스 작업을 시작했으며 기본 키가 현재 다양한 열에 클러스터되어 있습니다. 몇 가지 예 :

  • 날짜 / 문자
  • 날짜 / 정수
  • 날짜 / 시간
  • char / nvarchar / nvarchar

이에 대한 유효한 사례가 있습니까? 이 경우 항상 ID 또는 고유 식별자 열을 정의했을 것입니다.

또한 기본 키가없는 테이블이 많이 있습니다. 이것에 대한 유효한 이유는 무엇입니까?

나는 왜 테이블이 원래대로 디자인되었는지 이해하려고하는데, 그것은 나에게 큰 혼란으로 보이지만 그럴만 한 이유가있을 수 있습니다.

대답을 해독하는 데 도움이되는 세 번째 질문 : 복합 기본 키를 구성하기 위해 여러 열을 사용하는 경우이 방법과 대리 / 인공 키의 이점이 있습니까? 나는 주로 성능, 유지 관리, 관리 등과 관련하여 생각하고 있습니까?


나는 데이터베이스 기술 : 기본 키를 선택하는 Sane 접근 방식 이 잘 읽히고 설명 된 대부분의 요점을 따릅니다.
user2864740 1

답변:


254

몇 가지 규칙을 따릅니다.

  1. 기본 키는 필요한만큼 작아야합니다. 숫자 형식은 문자 형식보다 훨씬 간단한 형식으로 저장되므로 숫자 형식을 선호하십시오. 이는 대부분의 기본 키가 다른 테이블의 외래 키일뿐 아니라 여러 인덱스에 사용되기 때문입니다. 키가 작을수록 색인이 작을수록 사용할 캐시의 페이지 수가 줄어 듭니다.
  2. 기본 키는 절대 바뀌지 않아야합니다. 기본 키를 업데이트하는 것은 항상 문제가되지 않아야합니다. 여러 인덱스에서 사용되어 외래 키로 사용될 가능성이 높기 때문입니다. 단일 기본 키를 업데이트하면 변경으로 인한 파급 효과가 발생할 수 있습니다.
  3. "문제 기본 키"를 논리 모델 기본 키로 사용하지 마십시오. 예를 들어 여권 번호, 주민등록 번호 또는 직원 계약 번호는 이러한 "기본 키"는 실제 상황에 따라 변경 될 수 있습니다.

대리 키와 자연 키에 대해서는 위의 규칙을 참조하십시오. 자연 키가 작고 변경되지 않으면 기본 키로 사용할 수 있습니다. 자연 키가 크거나 변경 될 가능성이있는 경우 대리 키를 사용합니다. 기본 키가없는 경우 경험에 따르면 항상 스키마에 테이블을 추가하고 기본 키를 배치하기를 원하므로 대리 키를 만듭니다.


3
나는 그것을 좋아한다! "규칙"에 대한 문서가 있습니까? 감사!
로이드 Cotten면

4
아니요, 그냥 경험하십시오. "작은"데이터베이스를 다룰 때이 문제는 그다지 중요하지 않습니다. 그러나 큰 DB를 처리 할 때 작은 모든 것이 중요합니다. 텍스트 또는 guid를 사용하는 것과 비교하여 int 또는 long pk가있는 10 억 행이 있다고 상상해보십시오. 큰 차이가 있습니다!
Logicalmind

44
인공 키를 사용할 때 고유 키를 자연 키 (실제로는 존재하지 않는 경우)에 두는 것이 좋습니다.
HLGEM

3
@Lloyd Cotten : 다음은 빅 데이터 엔진 제공 업체가 규칙 1을 지원하는 내용입니다 : skyfoundry.com/forum/topic/24 . 그것은 다시 갈 것을 설득 Int
호브

4
"천연 키가 작고 절대 변하지 않을 것"을 "알고"도 두 번 생각하십시오. "우리는 절대로 그 코드를 재사용하지 않습니다"는 유명한 마지막 단어입니다 .... 작은 범주에 해당하는 유일한 내용은 iso 및 기타 표준 (국가 코드, iata 공항 코드,)입니다. "이 내부 브랜드의 2 글자 표현은 무엇입니까?"와 같은 것 ... "그것"이 절대 바뀌지 않을 것이라고 가정하기 전에 두 번 생각하십시오.
Andrew Hill

90

자연 구절 인공 열쇠는 데이터베이스 커뮤니티 사이에서 일종의 종교적인 논쟁입니다. 이 기사 와 관련 기사를 참조하십시오 . 나는 항상 인공적인 열쇠를 가지거나 결코 그것을 갖지 않는 것을 좋아하지 않습니다 . 사례별로 결정합니다. 예를 들면 다음과 같습니다.

  • 미국 : 텍사스의 경우 state_id = 1 대신 state_code (텍사스의 경우 'TX'등)로 이동합니다.
  • 직원 : 나는 일반적으로 인공 종업원 _id를 만듭니다. 왜냐하면 작동하는 다른 것을 찾기가 어렵 기 때문입니다. SSN 또는 이와 동등한 기능이 작동 할 수 있지만 아직 SSN을 제공하지 않은 새로운 조인과 같은 문제가있을 수 있습니다.
  • 직원 급여 내역 : (employee_id, start_date). 나는 할 수 없습니다 인공 employee_salary_history_id을 만들 수 있습니다. 어떤 시점에 도움이됩니까 ( "어리 석음 일관성" 제외)

인공 키가 사용되는 곳마다 항상 자연 키에 대한 고유 제한 조건을 선언해야합니다. 예를 들어, 필요한 경우 state_id를 사용하지만 state_code에 고유 제한 조건을 선언하는 것이 좋습니다. 그렇지 않으면 결국 다음과 같이 끝납니다.

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

9
일부 경우 SQL Server 2005/2008의 경우 자연 (텍스트) 키가 int 키보다 빠를 수 있습니다. 우리가 기본 키로 사용하고 int surrogate보다 더 빠르고 (종종 더 편리합니다) 7-8 자 친화적 인 코드가있는 앱이 있습니다. 어쨌든 다른 응용 프로그램 인스턴스 (더 큰 사이트로 집계되는 여러 사이트)와 충돌없이 안전하게 전송할 수있는 사람이 읽을 수 있고 기억하기 쉬운 코드를 가질 수 있도록 코드가 필요했습니다.
lambacck가

1
+1 좋은 답변입니다. 그러나 인사 담당자가 직원 식별자의 신뢰할 수있는 출처, 즉 SSN과 같은 식별자를 사용하거나 참조를 취하는 등 실제 직원을 확인하는 담당자가되도록해야합니다. 인사 부서는 신뢰할 수 있어야합니다. DBMS가 아닌 직원 식별자 소스!
onedaywhen

@ onedaywhen- 나는 않을 것입니다. 인사 담당관을 신뢰하십시오. 사람들은 떠나고 새로운 사람들은 와서 다른 생각을 가지고 있습니다. 그들에게 그들이 고유하다고 생각하는 식별자에 접근 할 수 있도록하세요. 그러나 dba를 위해 내부적으로 dba는 스스로 결정할 것입니다
Dave Pile

1
SSN이 모든 국가에서 고유 한 것은 아닙니다. 적어도 오스트리아에서는 여러 사람이 같은 수를 공유 할 수 있습니다.
maja

또한 일부 국가에서는 (미국에서도 생각합니다) 실제로 SSN을 공유하지 않는 것이 좋습니다.
Stijn de Witt

25

종종 간과되는 내용에 대한 추가 의견. 때로는 대리 키를 사용하지 않으면 자식 테이블에 이점이 있습니다. 하나의 데이터베이스 내에서 여러 회사를 운영 할 수있는 디자인이 있다고 가정 해 봅시다 (호스팅 된 솔루션 등).

이 테이블과 열이 있다고 가정 해 봅시다.

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

마지막 비트가 의미가없는 경우 Invoice.CompanyId하나는 CostCentre 테이블에 대한 하나와 CostElement 테이블 에 대한 두 개의 외래 키의 일부입니다 . 기본 키는 ( InvoiceId , CompanyId )입니다.

이 모델에서는 한 회사 의 CostElement 와 다른 회사 의 CostCentre 를 고정하고 참조 할 수 없습니다 . CostElementCostCentre 테이블 에서 서로 게이트 키를 사용한 경우 사용됩니다 .

망칠 확률이 적을수록 좋습니다.


6
이는 서로 게이트 키를 사용할 때 언급되지 않은 단점입니다. 테이블에 대리 키가 있으면 이러한 종류의 제약 조건에 여전히 사용할 수 있습니다. 불행히도 제약 조건에는 인덱스가 필요하지만 (surrogate_key) 자체가 고유 할 때 (surrogate_key, other_column)에 고유 인덱스를 생성하는 것은 이상합니다. 또한 (surrogate_key)는 외부 테이블에서 고유하기 때문에 (other_column)은 종종 맵 테이블에서 완전히 중복됩니다. 대리자는 실제로 일을 망칠 수 있습니다.
Samuel Danielson

24

인간의 실수라는 단순한 이유로 자연 키를 사용하지 마십시오. 고유 한 고유 식별자 (SSN, VIN, 계좌 번호 등)를 종종 사용할 수 있지만 사람이 올바르게 입력해야합니다. SSN을 기본 키로 사용하는 경우 누군가 데이터를 입력하는 동안 몇 개의 숫자를 바꾸고 오류가 즉시 발견되지 않으면 기본 키를 변경해야합니다.

내 기본 키는 모두 백그라운드에서 데이터베이스 프로그램에 의해 처리되며 사용자는이를 알지 못합니다.


1
SSN 또는 세금 ID를 기본 키로 사용하는 몇 가지 데이터베이스로 작업했습니다. 스토리지 및 외래 키 참조에있어 비효율적입니다. 개인의 SSN이 변경 될 수 있다는 것은 말할 것도 없습니다. 그래서 나는 당신에게 완전히 동의합니다.
Alex Jorgenson 2019

13

다양한 필드에서 기본 키를 만드는 데 아무런 문제가 없습니다 . 즉, 자연 키 입니다.

후보 필드의 고유 색인과 연관된 ID 열을 사용하여 Surrogate Key 를 만들 수 있습니다.

그것은 오래된 토론입니다. 대부분의 상황에서 대리 키를 선호합니다.

그러나 열쇠가 부족하다는 변명은 없습니다.

재 : 편집

예, 그것에 대해 많은 논란이 있습니다 : D

나는 자연 키가 자연 선택이라는 사실 외에도 자연 키에 명백한 이점을 보지 못합니다. 당신은 항상 생각합니다 이름, SocialNumber - 또는 그런 일 - 대신 idPerson .

대리 키는 자연 키의 몇 가지 문제에 대한 해답입니다 (예 : 변경 사항 전파).

대리하기에 익숙해지면 더 깨끗하고 관리하기 쉬워 보입니다.

그러나 결국, 그것은 맛의 문제 또는 사고 방식이라는 것을 알게 될 것입니다. 사람들은 자연적인 열쇠로 "더 나은 생각"을하고 다른 사람들은 그렇지 않습니다.


13
사람들은 자연스러운 열쇠로 "더 나은 생각"을합니다. 컴퓨터와 데이터베이스는 그렇지 않습니다.
FDCastel

11

테이블에는 항상 기본 키가 있어야합니다. 그렇지 않은 경우 자동 증가 필드 여야합니다.

때때로 사람들은 많은 양의 데이터를 전송하기 때문에 기본 키를 생략하고 프로세스에 따라 속도가 느려질 수 있습니다 (데이터베이스에 따라 다름). 그러나 그 후에 추가해야합니다.

link table에 대한 한 가지 의견 , 맞습니다. 그러나 예외를 유지하기 위해 FK 필드는 예외입니다. 그러나 링크에서 중복이 인증되지 않은 경우 해당 필드도 기본 키가 될 수 있습니다 ... 예외는 프로그래밍에서 종종 예외이기 때문에 데이터의 무결성을 유지하려면 기본 키가 있어야합니다.


나는 동의한다. 그리고 많은 양의 데이터가 삽입되는 경우 기본 키 제약 조건을 제거하거나 TSQL에서 INSERT IDENTITY ON을 사용하여 나중에 다시 넣습니다. :)
Andrew Rollings

1
예외가 있습니다 : 분명히 테이블 연결
annakata

또 다른 이유 : PK / 고유 키가 없으면 테이블 브라우저 (Access / SQL Server Management Studio와 같은 것)는 중복 된 행이있는 단일 행의 업데이트 / 삭제를 거부합니다. 이를 위해서는 SQL을 작성해야합니다.
Dennis C

데이터웨어 하우스 팩트 테이블에서 PK를 생략하는 것이 일반적입니다. (. 즉, 어딘가에 저장되지 변화를 기대하지 않는다) 오라클에서는 단기간에 고유 한 식별자로 ROWID 의사 열을 참조 할 수 있습니다
데이비드 드리지

9

모든 좋은 답변 게다가, 난 그냥 방금 읽은 좋은 기사, 공유 할 큰 기본 키 논쟁 .

몇 가지 요점을 인용하면 다음과 같습니다.

개발자는 각 테이블의 기본 키를 선택할 때 몇 가지 규칙을 적용해야합니다.

  • 기본 키는 각 레코드를 고유하게 식별해야합니다.
  • 레코드의 기본 키 값은 null 일 수 없습니다.
  • 레코드가 작성 될 때 기본 키-값이 존재해야합니다.
  • 기본 키는 안정적으로 유지되어야합니다. 기본 키 필드는 변경할 수 없습니다.
  • 기본 키는 크기가 작아야하며 가능한 가장 적은 속성을 포함해야합니다.
  • 기본 키 값은 변경할 수 없습니다.

자연 키는 규칙을 어기는 경향이 있습니다. 서로 게이트 키는 규칙을 준수합니다. (이 기사를 더 잘 읽으면 시간 가치가 있습니다!)


7

기본 키의 특별한 점은 무엇입니까?

스키마에서 테이블의 목적은 무엇입니까? 테이블 키의 목적은 무엇입니까? 기본 키의 특별한 점은 무엇입니까? 기본 키에 대한 논의는 기본 키가 테이블의 일부이고 해당 테이블이 스키마의 일부라는 점을 놓친 것 같습니다. 테이블 및 테이블 관계에 가장 적합한 것은 사용되는 키를 구동해야합니다.

테이블 (및 테이블 관계)에는 기록하려는 정보에 대한 사실이 포함됩니다. 이러한 사실은 독립적이며 의미 있고 이해하기 쉽고 모순되지 않아야합니다. 디자인 관점에서 스키마에서 추가 또는 제거 된 다른 테이블은 해당 테이블에 영향을 미치지 않아야합니다. 정보 자체에만 관련된 데이터를 저장하기위한 목적이 있어야합니다. 테이블에 저장된 내용을 이해하는 것은 과학적 연구 프로젝트를 거치지 않아도됩니다. 같은 목적으로 저장된 사실은 두 번 이상 저장해서는 안됩니다. 키는 기록되는 정보의 전체 또는 일부이며 고유하며 기본 키는 테이블에 대한 기본 액세스 지점이되도록 특별히 지정된 키입니다 (예 : 삽입이 아니라 데이터 일관성 및 사용을 위해 선택해야 함) 공연).

  • ASIDE : 불행히도 응용 프로그램 프로그래머가 설계하고 개발하는 대부분의 데이터베이스의 부작용은 (때로는 응용 프로그램 또는 응용 프로그램 프레임 워크에 가장 적합한 것이 종종 테이블의 기본 키를 선택한다는 것입니다. 이로 인해 정수 및 GUID 키 (응용 프로그램 프레임 워크에 사용하기 간단 함) 및 모 놀리 식 테이블 디자인 (메모리의 데이터를 나타내는 데 필요한 응용 프로그램 프레임 워크 개체 수가 감소됨)이 발생합니다. 이러한 응용 프로그램 중심의 데이터베이스 디자인 결정은 대규모로 사용될 때 중대한 데이터 일관성 문제를 야기합니다. 이러한 방식으로 설계된 응용 프로그램 프레임 워크는 자연스럽게 한 번에 테이블 디자인으로 이어집니다. "부분 레코드"는 시간이 지남에 따라 채워진 테이블 및 데이터에 작성됩니다. 다중 테이블 상호 작용을 피하거나 사용하면 응용 프로그램이 제대로 작동하지 않을 때 데이터가 일치하지 않습니다. 이러한 디자인은 의미가없는 (또는 이해하기 어려운) 데이터, 테이블에 분산 된 데이터 (현재 테이블을 이해하기 위해 다른 테이블을 살펴 봐야 함) 및 중복 된 데이터로 이어집니다.

기본 키는 필요한만큼 작아야한다고합니다. 키는 필요한만큼만 커야한다고 말합니다. 의미없는 필드를 테이블에 임의로 추가하는 것은 피해야합니다. 임의로 추가 된 무의미한 필드에서 키를 만드는 것은 특히 다른 테이블에서 기본 키가 아닌 키로의 조인 종속성을 제거 할 때 더 나쁩니다. 이는 테이블에 좋은 후보 키가없는 경우에만 합리적이지만 모든 테이블에 사용되는 경우 스키마 디자인이 잘못되었음을 나타냅니다.

또한 기본 키를 업데이트하면 항상 문제가 없어야하기 때문에 기본 키는 절대 바뀌지 않아야한다고합니다. 그러나 update는 delete와 insert와 동일합니다. 이 논리에 의해 하나의 키가있는 테이블에서 레코드를 삭제 한 다음 두 번째 키가있는 다른 레코드를 추가해서는 안됩니다. 서로 게이트 기본 키를 추가해도 테이블의 다른 키가 존재한다는 사실은 제거되지 않습니다. 기본 테이블이 아닌 키를 업데이트하면 다른 테이블이 서로 게이트 키 (예 : 상태 설명이 '처리됨'에서 '취소됨'으로 변경된 서로 게이트 키가있는 상태 테이블)를 통해 해당 의미에 종속되는 경우 데이터의 의미를 파괴 할 수 있습니다. '데이터를 손상시킬 수 있습니다). 항상 의문의 여지가없는 것은 데이터의 의미를 파괴하는 것입니다.

이것을 말하면서, 나는 오늘날 비즈니스에 존재하는 제대로 설계되지 않은 많은 데이터베이스 (무의미한 대리 키 데이터 손상-1NF 거대 함)에 대해 감사합니다. . 그러나 슬픈 측면에서 때로는 시시 푸스처럼 느껴지지만 (충돌 전) 그는 401k의 지옥을 가지고 있다고 확신합니다. 중요한 데이터베이스 디자인 관련 질문은 블로그 및 웹 사이트에서 멀리하십시오. 데이터베이스를 디자인하는 경우 CJ Date를 찾으십시오. Celko를 SQL Server로 참조 할 수도 있지만 코를 먼저 잡고 있어야합니다. Oracle 측에서는 Tom Kyte를 참조하십시오.


1
"이 논리에 의해 하나의 키가있는 테이블에서 레코드를 삭제 한 다음 두 번째 키가있는 다른 레코드를 추가해서는 안됩니다." -이에 대한 경우가 있으며, 외래 키에 대한 "ON DELETE RESTRICT"절이 효과적으로 수행됩니다. 경우에 따라 (감사 추적이 필요한 경우) "삭제 된"부울 필드가 레코드를 삭제하는 것보다 낫습니다.
Waz

6

가능한 경우 자연 키가 가장 좋습니다. 따라서 datetime / char가 고유하면 가 행을 식별하고 두 부분이 행에 의미가 있다면 훌륭합니다.

날짜 시간 만 의미가 있고 문자를 독특하게 만들기 위해 방금 고정 된 경우 식별 필드를 사용할 수도 있습니다.


9
보통 최고? 나는 과학적 근거가 없지만 거의 모든 사람들이 자연보다 대리 키를 선호합니다. 많은 경우 자연 키가 없습니다.
JC.

3
데이터베이스의 모든 행에 대해 항상 자연스러운 키가 있어야합니다. "천연"키는 비즈니스 세계 나 기술 시스템에서 생성 된 것일 수 있지만 항상 존재해야합니다.
Tom H

2
당신의 세계에서 그것이 테이블의 행을 식별하는 유일한 방법이라고 결정된 경우라면 그렇습니다. 물론, 설계자가 PK에 대한 GUID를 생성하기로 선택한 경우 일반적으로 REAL 자연 키를 찾기위한 작업을 수행하지 않았기 때문에 GUID가 자연 키가 아닙니다.
Tom H

8
2. 자연 세계에서 열쇠를 가져 가면 자연 세계가 열쇠를 깰 수 있도록 변경됩니다. 전화 번호를 사용하면 같은 세대의 사용자 두 명을 얻게됩니다. 성을 사용하면 결혼합니다. SSN을 사용하는 경우 개인 정보 보호법이 변경되어 제거해야합니다.
James Orr

2
@Barry : RE : # 2. 자연 세계가 변하고 자연 키가 변경되는 경우 자연 키를 선택하는 데 실패했습니다. 정의에 따라 자연 키는 시간이 지나도 변경되지 않습니다.
Tom H

6

다음은 25 년 이상의 개발 경험을 바탕으로 정한 본인의 경험 규칙입니다.

  • 모든 테이블에는 자동 증분되는 단일 열 기본 키가 있어야합니다.
  • 업데이트 할 수있는보기에 포함하십시오
  • 기본 키는 응용 프로그램과 관련하여 의미가 없어야합니다. 즉, SKU, 계좌 번호 또는 직원 ID 또는 응용 프로그램에 중요한 기타 정보가 아니어야합니다. 엔터티와 관련된 고유 키일뿐입니다.

기본 키는 최적화 목적으로 데이터베이스에서 사용되며 특정 엔터티를 식별하거나 특정 엔터티와 관련된 것 이상으로 응용 프로그램에서 사용해서는 안됩니다.

항상 단일 값 기본 키를 사용하면 UPSERT를 매우 간단하게 수행 할 수 있습니다.

추가 색인을 사용하여 응용 프로그램에서 의미가있는 다중 열 키를 지원하십시오.


5

자연스럽고 인공적인 키는 데이터베이스에서 원하는 비즈니스 로직의 양에 달려 있습니다. 사회 보장 번호 (SSN)가 좋은 예입니다.

"데이터베이스의 각 클라이언트에는 SSN이 있어야합니다." Bam, 기본 키로 만들고 완료하십시오. 비즈니스 규칙이 언제 불타는 지 기억하십시오.

나는 비즈니스 규칙을 변경 한 경험으로 인해 자연스러운 키를 좋아하지 않습니다. 그러나 변경되지 않는 것이 확실하다면 몇 가지 중요한 조인을 막을 수 있습니다.


8
그리고 SSN이 독특하지 않은 데이터를 보았습니다. 다른 소스에서 데이터를 가져 오는 경우 자연 키에 매우주의하십시오!
HLGEM

2
신분 도용의 대상인 경우 사회 보장 번호를 변경할 수 있습니다. 그들이 당신의 번호를 바꿀 4 가지 상황이 더 있으며 ssa.gov 사이트에 나와 있습니다.
Zvi Twersky

4

Steven A. Lowe의 롤업 신문 치료가 원래 데이터 구조의 설계자에게 필요하다고 생각합니다.

제쳐두고, GUID가 기본 키가 성능 돼지 일 수있다. 나는 그것을 추천하지 않을 것입니다.


2
성능 호그를 말하는 것은 조기 최적화입니다. 경우에 따라 Guid가 필요합니다 (연결이 끊긴 클라이언트, 향후 테이블 병합, 복제)
JC.

2
"조기 최적화"는 SO (IMHO)에서 과용 된 문구입니다! 예, 경우에 따라 GUID가 필요할 수 있지만 Andrew는 필요한지 여부에 관계없이 기본 데이터 유형으로 사용해서는 안된다고 지적 할 수 있습니다.
토니 앤드류스

실제로 실제로 조기 최적화 된 것은 아닙니다. 내가 의미하는 바는 대부분의 사람들이 성능 차이를 알아내는 데 필요한 볼륨을 경험하지 않는다는 것입니다. 예, guid가 필요하지 않다는 것을 알고 있다면 자동 증분을 사용하십시오.
JC.

또는 둘 다 사용하십시오. 빠른 선택 및 조인을 위해 int / long 기반 기본 키가 있고 guid 필드가 있습니다. 적어도, 내가하고있는 일입니다. 이것이 잘못 되었습니까? 내가 그렇게하지 말아야합니까? :)
Andrew Rollings

또한 두 열을 모두 사용하고 있습니다. 그러나 그것이 잘못되었는지 확실하지 않습니다. @AndrewRollings를 찾았습니까?
YÒGÎ

3

여러 필드로 구성된 '복합'또는 '복합'기본 키를 사용해야합니다.

이것은 완벽하게 수용 가능한 솔루션 입니다. 자세한 정보 는 여기 로 이동 하십시오. :)


3

나도 항상 숫자 ID 열을 사용합니다. 오라클에서는 number (12,0) 이상의 실제 이유없이 숫자 (18,0)를 사용합니다 (또는 long이 아닌 int가 무엇이든). db!

또한 기본 추적을 위해 생성되고 수정 된 열 (유형 타임 스탬프)도 포함되어 있습니다.

다른 열 조합에 대해 고유 한 제약 조건을 설정하는 것은 중요하지 않지만 ID가 생성되고 수정 된 기준 요구 사항을 정말로 좋아합니다.


2
또한 링크 / 결합 테이블에 ID를 넣지 않고 데이터가 포함 된 테이블에만 ID를 넣지 않아야합니다.
JeeBee

3

자연스러운 기본 키를 찾아 가능한 한 사용합니다.

자연 키를 찾을 수 없으면 SQL Server가 트리를 사용하기 때문에 INT ++보다 GUID를 선호하며 트리의 끝에 항상 키를 추가하는 것은 좋지 않습니다.

다 대다 커플 링 인 테이블에서는 외래 키의 복합 기본 키를 사용합니다.

SQL Server를 사용할만큼 운이 좋기 때문에 프로파일 러 및 쿼리 분석기를 사용하여 실행 계획 및 통계를 연구하고 내 키의 성능을 쉽게 확인할 수 있습니다.


이 문장을 뒷받침하는 문서가 있습니까? '자연 키를 찾을 수 없으면 SQL Server가 트리를 사용하기 때문에 INT ++보다 GUID를 선호하며 항상 트리 끝에 키를 추가하는 것은 좋지 않습니다.' 회의적이지 않고 일부 문서를 컴파일하려고합니다.
로이드 Cotten면

1
@Lloyd-제가 매우 흥미로워하는 것에 관심을 가져 주셔서 감사합니다. msdn.microsoft.com/en-us/library/ms177443(SQL.90).aspx
Guge

2

항상 자동 번호 또는 ID 필드를 사용합니다.

SSN을 기본 키로 사용한 클라이언트에서 근무한 후 HIPAA 규정으로 인해 "MemberID"로 변경되어 관련 테이블에서 외래 키를 업데이트 할 때 많은 문제가 발생했습니다. 일관된 ID 열 표준을 고수함으로써 모든 프로젝트에서 비슷한 문제를 피할 수있었습니다.


6
개발자가 자연 키를 잘못 선택했다고해서 자연 키가 잘못되었다는 의미는 아닙니다.
Tom H

1
사용하기 어려운 도구는 어떤 식 으로든 그 도구와 반대되는 점이 아닙니다.
Sqeaky

1

모든 테이블 에는 기본 키 있어야합니다. 그렇지 않으면, 당신이 가진 것은 HEAP입니다-이것은 어떤 상황에서, 당신이 원하는 것일 수 있습니다 (데이터가 서비스 브로커를 통해 다른 데이터베이스 또는 테이블에 복제 될 때 무거운 삽입로드).

행 수가 적은 룩업 테이블의 경우 3 CHAR 코드를 기본 키로 사용할 수 있습니다.이 키는 INT보다 공간을 덜 차지하지만 성능 차이는 무시할 수 있습니다. 그 외에는 관련 테이블의 외래 키로 구성된 복합 기본 키가있는 참조 테이블이 없으면 항상 INT를 사용합니다.


1

이 오래된 토론에 대한 앞뒤를 모두 읽고 싶다면 Stack Overflow에서 "natural key"를 검색하십시오. 결과 페이지를 다시 가져와야합니다.


1

GUID 를 기본 키로 사용할 수 있지만 제대로 작동하려면 올바른 유형의 GUID를 만들어야합니다.

COMB GUID를 생성해야합니다. 이에 대한 좋은 기사와 성능 통계는 기본 키로서의 GUID 비용입니다 .

또한 SQL 에서 COMB GUID를 빌드하는 일부 코드 는 Uniqueidentifier vs identity ( 아카이브 )에 있습니다.


5
IMHO, guid는 데이터베이스간에 데이터를 동기화해야 할 때만 사용해야합니다. 자동 생성 된 ID에 문제가 있습니다. guid를 사용하는 것과 기본 숫자 유형을 사용하는 것의 차이점은 guid는 행당 16 바이트가 필요하지만 숫자는 훨씬 작다는 것입니다.
Logicalmind

위의 링크로 이동하면 COMB Guid를 사용하는 성능에 거의 차이가 없습니다.
도니 V.

0

우리는 많은 조인을 수행하고 복합 기본 키는 성능을 향상시킵니다. 간단한 int 또는 long은 두 번째 후보 키를 도입하더라도 많은 문제를 처리하지만 한 필드에서 세 개의 필드로 결합하는 것이 훨씬 쉽고 이해하기 쉽습니다.


1
이 전략은 복합 키가 전파되지 않았기 때문에 필요한 실제 두 테이블을 결합하기 위해 6 개의 테이블을 순회해야 할 때 분리됩니다. 또한 여러 개의 인서트에 루프 / 커서를 사용하여 엄청난 성능을 발휘할 수 있습니다.
Tom H

2
나는 새로운 것을 배우기 위해 크지 않습니다. 나는 당신이하는 말의 예를보고 싶습니다.이 종교적인 주장들에 약간의 합리적인 사실을 주입하는 것이 도움이 될 것입니다.
Dan Blair

0

자연 키에 대한 선호도에 대해 먼저 설명하겠습니다. 데이터베이스 관리를 훨씬 쉽게 수행 할 수 있도록 가능한 경우 키를 사용하십시오. 회사에서 모든 테이블에 다음 열이 있다는 표준을 설정했습니다.

  • 행 ID (GUID)
  • 작성자 (문자열, 현재 사용자 이름의 기본값이 있음 ( SUSER_SNAME()T-SQL))
  • 작성 (DateTime)
  • 타임 스탬프

행 ID는 테이블마다 고유 한 키를 가지고 있으며, 모든 경우에 행마다 자동 생성되며 (권한은 누구나 편집 할 수 없음) 모든 테이블과 데이터베이스에서 고유하게 보장됩니다. ORM 시스템에 단일 ID 키가 필요한 경우 이것이 사용됩니다.

한편, 실제 PK는 가능하면 자연스러운 열쇠입니다. 내 내부 규칙은 다음과 같습니다.

  • 사람-대리 키를 사용하십시오 (예 : INT). 내부에있는 경우 Active Directory 사용자 GUID를 사용할 수 있습니다.
  • 조회 테이블 (예 : StatusCode)-짧은 CHAR 코드를 사용하십시오. INT보다 기억하기가 더 쉬우 며, 대부분의 경우 종이 양식과 사용자는 간결성을 위해이를 사용합니다 (예 : "만료 됨"의 상태 = "E", "승인 됨"의 경우 "A", "석면 없음"의 경우 "NADIS" 샘플에서 ")
  • 테이블을 연결 - FKS의 조합 (예를 들어 EventId, AttendeeId)

따라서 이상적으로는 사람이 읽을 수 있고 자연스럽게 읽을 수있는 자연 PK와 ORM 친화적 인 테이블 당 GUID로 끝나는 것이 이상적입니다.

주의 사항 : 내가 유지 관리하는 데이터베이스는 수백만 또는 수십 억이 아닌 100,000의 레코드에 경향이 있으므로 조언을 금하는 더 큰 시스템에 대한 경험이 있다면 저를 무시하십시오!


1
둘 다 만들 것을 제안하고 있습니까? GUID INT강력한 자연 키가없는 테이블에 대해 SK SK를 있습니까?

꼭 필요한 것은 아니지만 장점은 다음과 같습니다. a) 필요한 경우 복제가 더 쉬워집니다. b) ORM을 처리 할 때 저장하기 전에 코드에서 개체에 고유 한 ID를 할당 할 수 있습니다. 저장하기 전에 세션 캐시에 저장하는 것이 좋습니다. 열쇠는이 instace의 INT입니다. GUID는 보너스 일뿐입니다.
Keith Williams
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.