복합 기본 키와 추가 "ID" 열?

복합 기본 키와 추가 "ID" 열?

이런 테이블이 있다면,

책(ISBN이 없는 것처럼 가장)

• 작가.
• 제목
• 판
• 발행년도
• 가격.

{Author,Title,Edition}이(가) 후보/기본 키일 수 있다고 주장할 수 있습니다.

후보/기본 키가 {Author,Title,Edition}이어야 하는지 또는 {Author,Title,Edition} 고유 인덱스/키 제약 조건을 가진 ID 열을 사용해야 하는지 여부를 결정하는 요소는 무엇입니까?

그렇습니다

• 작성자(PK)
• 제목(PK)
• 에디션(PK)
• 발행년도
• 가격.

더 나은, 또는:

• ID(PK)
• 작가.
• 제목
• 판
• 발행년도
• 가격.

여기서 {Author,Title,Edition}은(는) 추가 고유 인덱스/제약 조건입니까?

그렇게 말하시오{Author, Title, Edition}책을 고유하게 식별하며, 다음이 유지됩니다.

1. 이것은 튜플(행)을 고유하게 식별하는 슈퍼키입니다.

2. 축소할 수 없습니다. 열을 제거해도 더 이상 키가 되지 않습니다.

3. 이것은 후보 키입니다. 축소할 수 없는 슈퍼키는 후보 키입니다.

이제 ID(정수)를 고려해 보겠습니다.

나는 추론할 수 있습니다.Book테이블 키는 외부 키로 표시되는 다른 테이블과 인덱스에도 표시됩니다.따라서 각 테이블에 있는 열 세 개 x 40자(또는 어떤 식으로든)와 일치하는 인덱스에는 상당한 공간이 필요합니다.

이러한 "기타" 테이블 및 인덱스를 더 작게 만들기 위해 고유 정수 열을 다음에 추가할 수 있습니다.Book외래 키로 참조될 키로 사용할 테이블.다음과 같은 말을 합니다.

alter table Book add BookID integer not null identity;

와 함께BookID또한 (반드시) 독특해야 합니다.Book테이블에는 이제 두 개의 후보 키가 있습니다.

이제 선택할 수 있습니다.BookID기본 키로

alter table Book add constraint pk_Book primary key (BookID);

하지만, 그{Author,Title,Edition} 다음과 같은 문제를 방지하려면 키(키)를 유지해야 합니다.

BookID  Author      Title           Edition
-----------------------------------------------
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

요약하자면, 다음을 추가됩니다.BookID그리고 그것을 1차로 선택했습니다. 멈추지 않았습니다.{Author, Title, Edition}키가 되는 것여전히 고유한 제약 조건과 일반적으로 일치하는 인덱스가 있어야 합니다.

또한 설계 관점에서 이 결정은 "물리적 수준"에서 이루어졌습니다.일반적으로, 설계의 논리적인 수준에서, 이것은ID존재하지 않습니다. 열 크기 및 인덱스를 고려하는 동안 도입되었습니다.물리적 스키마는 논리적 스키마에서 파생되었습니다.DB 크기, RDBMS 및 사용된 하드웨어에 따라, 크기 추론은 측정 가능한 효과를 가질 수 없습니다. 따라서 사용합니다.{Author, Title, Edition}다르게 증명되기 전까지는 PK가 완벽하게 좋은 디자인일 수 있기 때문입니다.

일반적으로 기본 키의 값이 변경되지 않도록 해야 합니다.따라서 블라인드 또는 대리 기본 키가 사용됩니다.

기본 키의 일부로 작성자가 있는 독서 테이블을 만들었다고 가정합니다.

"레이 브래드버리"의 철자를 잘못 쓴 것을 약 1년 후에 알게 되었다고 가정해 보겠습니다.더 나쁜 것은, "Rachael Bloom"의 철자를 잘못 썼다는 것입니다.철자 오류를 수정하기 위해 수정해야 하는 데이터베이스 행의 수를 상상해 보십시오.얼마나 많은 인덱스 참조를 변경해야 하는지 상상해 보십시오.

그러나 대체 키가 있는 작성자 테이블이 있는 경우에는 한 행만 수정하면 됩니다.인덱스를 변경할 필요가 없습니다.

마지막으로, 데이터베이스 테이블 이름은 일반적으로 복수(책)가 아닌 단일(책)입니다.

대리 기본 키 시나리오를 사용하는 또 다른 좋은 이유는 고유성 제약 조건이 미래에 변경되어야 하는지 여부입니다(예: 책을 고유하게 만들기 위해 ISBN을 추가해야 함).데이터 키를 다시 누르는 것이 훨씬 쉬워질 것입니다.

이와 관련된 기사가 많습니다.사용자의 경우 복합 키의 문제:

1. 책과 다른 실체를 연결하기 어려운
2. 대부분의 그리드가 복합 키(예: kendo grid, jqgrid)를 지원하지 않기 때문에 그리드에서 편집하기 어렵습니다.
3. 작성자, 제목, 버전의 철자가 틀릴 수 있습니다.

(dasblinkenlight)가 제안한 것처럼 데이터를 정규화하고 작성자에게 ID만 저장하는 것도 좋을 것입니다.최악의 경우, 그/그녀는 이름을 바꿀 것입니다(예: 그녀는 결혼을 했고, 그녀의 새 이름을 좋아합니다).

언급URL : https://stackoverflow.com/questions/14588304/composite-primary-key-vs-additional-id-column