여러 열을 기본 키로 사용하는 이유 (복합 기본 키)

이 예제는 w3schools에서 가져온 것 입니다 .

CREATE TABLE Persons
(
    P_Id int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255),
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)

내 이해는 두 열이 함께 ( P_Id및 LastName) 테이블의 기본 키를 나타냅니다 Persons. 이 올바른지?

• 누군가가 단일 열 대신 여러 열을 기본 키로 사용하려는 이유는 무엇입니까?
• 주어진 테이블에서 기본 키로 함께 사용할 수있는 열은 몇 개입니까?

이해가 정확합니다.

많은 경우에 이것을 할 것입니다. 한 가지 예는 같은 관계에 OrderHeader와 OrderDetail. 약동학에가 OrderHeader있을 수 있습니다 OrderNumber. 의 PK는 AND OrderDetail일 수 있습니다 . 둘 중 하나라면 고유하지 않지만 둘의 조합은 고유하게 보장됩니다.OrderNumberLineNumber

대안은 생성 된 (비 지능적인) 기본 키를 사용하는 것입니다 (예 :이 경우) OrderDetailId. 그러나 당신은 항상 관계를 쉽게 볼 수는 없습니다. 어떤 사람들은 한 가지 방법을 선호합니다. 일부는 다른 방법을 선호합니다.

복합 기본 키의 또 다른 예는 연관 테이블의 사용입니다. 사람 집합이 포함 된 사람 테이블과 그룹 집합이 포함 된 그룹 테이블이 있다고 가정합니다. 이제 사람과 그룹에 다 대다 관계를 만들고 싶습니다. 각 사람이 여러 그룹에 속할 수 있음을 의미합니다. 다음은 복합 기본 키를 사용하는 테이블 구조의 모습입니다.

Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))

Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))

Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))

W3Schools 예제는 복합 기본 키를 사용해야하는시기를 말하는 것이 아니라 다른 키와 동일한 예제 테이블을 사용하는 예제 구문 만 제공합니다.

그들이 선택한 예는 의미없는 키 (P_Id)와 자연 키 (LastName)를 결합하여 사용자를 오도 할 수 있습니다. 이 이상한 기본 키 선택은 다음 행이 스키마에 따라 유효하며 학생을 고유하게 식별하는 데 필요함을 나타냅니다. 직관적으로 이것은 말이되지 않습니다.

1234     Jobs
1234     Gates

더 읽을 거리 : 위대한 기본 토론 또는 Google meaningless primary keys또는 심지어 이것을 정독하십시오. SO 질문을

FWIW-내 2 센트는 다중 열 기본 키를 피하고 생성 된 단일 ID 필드 (대리 키)를 기본 키로 사용하고 필요한 경우 추가 (고유) 제약 조건을 추가하는 것입니다.

여러 속성 조합의 고유성을 보장하고자 할 때마다 복합 키 (둘 이상의 속성이있는 키)를 사용합니다. 단일 속성 키는 동일한 결과를 얻지 못합니다.

예, 둘 다 기본 키를 형성합니다. 특히 서로 게이트 키 가없는 테이블에서는 각 레코드의 고유 식별자로 여러 속성을 지정해야 할 수 있습니다 (나쁜 예 : 이름과 성이 모두있는 테이블의 경우 두 속성의 조합이 독특한).

일반적으로 키의 여러 열은 대리 키보다 성능이 떨어집니다. 저는 서로 게이트 키와 다중 열 키에 대한 고유 인덱스를 선호합니다. 이렇게하면 더 나은 성능을 얻을 수 있고 필요한 고유성이 유지됩니다. 더 좋은 점은 해당 키의 값 중 하나가 변경 될 때 215 개의 하위 테이블에서 백만 개의 하위 항목을 업데이트 할 필요가 없다는 것입니다.

두 번째 질문

주어진 테이블에서 기본 키로 함께 사용할 수있는 열은 몇 개입니까?

구현에 따라 다릅니다. 실제 사용중인 DBMS에 정의되어 있습니다. ^{[1], [2], [3]} 사용하는 데이터베이스 시스템의 기술 사양을 검사해야합니다. 일부는 매우 상세하고 일부는 그렇지 않습니다. 용어가 다양하기 때문에 이러한 제한 사항에 대해 웹을 검색하는 것은 어려울 수 있습니다. 복합 기본 키라 는 용어 는 필수 여야합니다.)

명시적인 정보를 찾을 수 없으면 테스트 데이터베이스를 만들어 제한 위반 (예상되는)에 대한 안정적이고 구체적인 처리를 기대할 수 있는지 확인하십시오. 이에 대한 올바른 정보를 얻으려면주의하십시오. 때때로 제한이 누적되고 다른 데이터베이스 레이아웃으로 다른 결과를 볼 수 있습니다.

• ^[1] sql-복합 기본 키 제한? - 스택 오버플로
• ^[2] SQL Server-기본 키당 최대 열
• ^[3] Oracle 9i 및 10g의 테이블에서 기본 키의 일부가 될 수있는 최대 열 수는 몇 개입니까?

관계형 데이터베이스에서 중간 테이블을 사용할 때 여러 테이블에서 기본 키를 사용하면 편리합니다.

예를 들어 이전에 만든 데이터베이스를 사용하고 특히 해당 테이블 내에있는 세 개의 테이블을 사용하겠습니다. 몇 년 전에 웹 만화 용 데이터베이스를 만들었습니다. 모든 만화, 제목, 이미지 파일 이름 등의 목록 인 "comics"라는 테이블 하나가 있습니다. 기본 키는 "comicnum"이었습니다.

두 번째 표는 이름과 간단한 설명 인 "문자"였습니다. 기본 키는 "charname"에 있습니다.

일부 예외를 제외하고 각 만화에는 여러 캐릭터가 있고 각 캐릭터가 여러 만화에 등장했기 때문에이를 반영하기 위해 "캐릭터"또는 "만화"에 열을 넣는 것은 비현실적이었습니다. 대신에 "comicchars"라는 세 번째 테이블을 만들었습니다.이 테이블은 어떤 만화에 어떤 캐릭터가 등장했는지 목록입니다. 이 테이블은 본질적으로 두 테이블을 조인했기 때문에 charname과 comicnum이라는 두 개의 열이 필요했고 기본 키는 둘 다에있었습니다.

단일 레코드를 구성하는 고유성 열 값을 보장하기 위해 복합 기본 키를 만듭니다. 중복되어서는 안되는 데이터의 삽입을 방지하는 제약입니다.

즉 : 모든 학생 ID와 출생 증명서 번호가 한 사람에게 고유하게 할당 된 경우. 그런 다음 다른 학생 ID와 동일한 출생 증명서를 가진 두 사람을 실수로 삽입하는 것을 방지 할 수 있으므로 개인의 기본 키를 학생 ID와 출생 증명서 번호의 조합으로 만드는 것이 좋습니다.