테이블의 모든 열을 구성하는 기본 키의 이점이 있습니까?

나는 널이 불가능한 네 개의 열이있는 테이블을 가지고 있으며 데이터는 고유 한 레코드를 구별하는 데 필요합니다. 이것은 기본 키를 만들려면 모든 열을 구성해야 함을 의미합니다. 테이블에 대한 쿼리는 거의 항상 단일 레코드를 가져와야합니다. 즉, 모든 열이 쿼리에서 필터링됩니다.

모든 열을 검색해야하므로 기본 키를 갖는 것이 전혀 도움이되지 않습니까 (레코드의 고유성을 강화하는 것 외에)?

귀하의 경우 이러한 필드는 자연스러운 열쇠입니다.

대리 키 :

서로 게이트 키는 "비즈니스"의미가없고 테이블에서 레코드를 식별하는 데만 사용되는 키입니다. 이러한 키는 데이터베이스 생성 (예 : SQL Server의 ID, Oracle의 시퀀스, DB2 UDB의 시퀀스 / ID 등) 또는 시스템 생성 값 (스키마의 테이블을 통해 생성 된 것)입니다.

자연 키 :

키가 나타내는 속성이 데이터베이스 스키마와 독립적으로 식별에 사용되는 경우 키는 자연 스럽습니다. 이것이 기본적으로 의미하는 것은 사람들이 키를 사용하면 키가 자연 스럽다는 것입니다 : 청구서 번호, 세금 ID, SSN 등

기본 키의 대리 키와 자연 키

비즈니스 및 데이터베이스 모델 관리를 분리하기 위해 대리 키를 추가하는 것을 선호합니다. 다른 질문은 기본 키에서 클러스터 된 인덱스와 비 클러스터형 인덱스를 사용하는 것입니다. 정적 테이블이 아닌 테이블 변경 사항을 테이블에 삽입하면 높은 인서트 나 업데이트가 발생합니다. 비단 조 증가 키에서 클러스터 된 인덱스를 사용하는 경우 성능에 문제가 있습니다.

일반적으로 이러한 상황에서는 대리 키를 사용하는 것이 좋습니다. 따라서 다른 테이블의 외래 키 (및 외부에서 저장 될 수있는 레코드 참조 (예 : http 요청이 하나를 참조하는 쿼리 문자열에서 수행되는 경우)) 행의 데이터가 변경되면 변경되지 않는 참조 할 내용이 있습니다. 이렇게하면 기본 키가됩니다.

그러한 대리 키를 추가하지 않으면 네 개의 열을 모두 기본 키로 사용하여 액세스하는 데이터를 설명하는 방법이 불리하지 않습니다. 키를 테이블의 클러스터형 인덱스로 만들면 디스크의 b- 트리에 한 수준이있어 주어진 행에 대한 데이터를 찾기 위해 요청을하는 데 도움이됩니다.

기본 키인 복합 키는 디스크 사용, IO 속도 및 백업에 영향을 줄 수있는 인덱스 크기 문제도 발생합니다. 기본 키 및 클러스터형 인덱스에 대한 Kimberly Tripp의 게시물을 여기에서 검토 할 수 있습니다. http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

이 경우에도 자연스러운 키 대신 대리 키를 제안합니다.

열이 2 개인 다 대다 관계를 나타내는 테이블이 있으면 합리적으로 보입니다.

Cf. 이 SO 질문

그러나 나는 그런 경우에도 대리 키를 추가한다는 것을 인정합니다.