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

Program / 글쓴이

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

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

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

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

질문 🙂

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

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

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

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

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

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

답변

몇 가지 규칙을 따릅니다.

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

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

답변

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

  • 미국 : 텍사스의 경우 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

답변

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

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

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 를 고정하고 참조 할 수 없습니다 . CostElement 및 CostCentre 테이블 에서 서로 게이트 키를 사용한 경우 사용됩니다 .

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

답변

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

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

답변

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

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

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

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

재 : 편집

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

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

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

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

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

답변

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

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

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

답변

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

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

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

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

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