GUID없이 Natural Identity Columns를 사용해야합니까?

Question

조합이 고유해야하는 2 개의 외래 키 열이있는 테이블 기본 키를 정의해도 괜찮습니까? 따라서 새로운 id 열 (Guid 또는 int)을 추가하지 않습니까?

부정적인 점이 있습니까?

Answer 1

예, 완전히 정상입니다. 왜 안돼? 복합 기본 키의 단점은 길기 때문에 애플리케이션 관점에서 단일 행을 고유하게 식별하는 것이 어려울 수 있다는 것입니다. 그러나 두 개의 정수 열 (특히 접합 테이블)에서는 좋은 방법입니다.

Answer 2

일부 "ok"정의의 경우 예. 이 교차로 테이블에 필드를 추가하지 않으려면 괜찮습니다. 그러나 필드가 더 많으면 ID 필드가있는 것이 좋습니다. 여전히 괜찮아요, 생각해 보니 더 어색 할 수 있습니다.

물론 디스크 공간에 심각한 프리미엄이없는 한!

Answer 3

데이터베이스 교과서를 살펴보면 그러한 테이블을 한꺼번에 볼 수 있습니다. 이것이 n-to-m 관계를 정의하는 기본 방법입니다. 예를 들어 :

article = (id, title, text) 
author = (id, name) 
article_author = (article_id, author_id) 

는 의미 적, article_author는 기본 키로 정의 자제하고 대신 UNIQUE 제약 조건을 가진 정상적인 인덱스로 만들 수 있도록 새로운 실체가 아니다.

Answer 4

예, 동의합니다. "OK 정의 중 일부입니다."괜찮습니다. 그러나이 복합 기본 키를 어딘가에서 참조하기로 결정 (즉, 외래 키로 이동)하면 NG (좋지 않음)를 신속하게 나타냅니다.

Answer 5

자연 대 인공 주키는 광범위하게 토론되는 이슈 중 하나이며이 논의는 위치가 단단 해지는 것을 보는 것 같습니다.

제 생각에는 개발자가 두 가지 단점을 피하는 방법을 알고있는 한 둘 다 오랫동안 작동합니다. 자연스러운 기본 키 (복합 또는 단일 열)는 중복 행이 DB에 추가되지 않도록합니다. 인공 기본 키를 사용하는 경우 레코드가 고유한지 확인해야합니다 (인공 키는 항상 고유 할 기본 키와 반대입니다). 이를 달성하는 한 가지 효과적인 방법은 레코드를 고유하게 만드는 필드에 고유 색인 또는 후보 색인을 갖는 것입니다 (예 : 기본 키의 후보를 만드는 필드)

한편 인위적인 기본 키를 사용하면 쉽게 가입 할 수 있습니다. 관계는 단일 필드 - 단일 필드 조인으로 만들 수 있습니다. 복합 키를 사용하면 SQL 문의 작성자는 조인에 포함 할 필드 수를 알아야합니다.