각 테이블마다 기본 키가 있어야합니까?

데이터베이스 테이블을 만들고 있는데 논리 기본 키가 할당되어 있지 않습니다. 그래서 나는 기본 키없이 그것을 떠날 생각하고 있지만 그것에 대해 약간의 죄책감을 느낍니다. 내가해야합니까?

각 테이블마다 기본 키가 있어야합니까?

짧은 대답 : 예 .

긴 대답 :

• 테이블을 무언가에 조인 할 수 있어야합니다.
• 테이블을 클러스터링하려면 일종의 기본 키가 필요합니다.
• 테이블 디자인에 기본 키가 필요하지 않은 경우 디자인을 다시 생각해보십시오. 왜 동일한 기록을 유지합니까?

MySQL에서 InnoDB 스토리지 엔진은 명시 적으로 지정하지 않으면 항상 기본 키를 생성하므로 액세스 할 수없는 추가 열이 생성됩니다.

기본 키는 복합 일 수 있습니다.

다 대다 링크 테이블이있는 경우 링크와 관련된 모든 필드에 기본 키를 만듭니다. 따라서 하나의 링크를 설명하는 두 개 이상의 레코드가 없는지 확인하십시오.

논리적 일관성 문제 외에도 대부분의 RDBMS 엔진은 이러한 필드를 고유 한 인덱스에 포함시키는 이점이 있습니다.

또한 기본 키에는 고유 인덱스 생성이 포함되므로이를 선언하고 논리적 일관성과 성능을 모두 확보해야합니다.

고유 데이터에 대해 항상 고유 색인을 작성해야하는 이유는 내 블로그에서이 기사를 참조하십시오.

• 고유 인덱스 만들기

PS는 몇 가지가있다 아주, 아주 기본 키를 필요로하지 않는 특별한 경우를.

대부분 그들은이없는 로그 테이블 등 어떤 성능상의 이유로 인덱스를.

항상 기본 키를 사용하는 것이 가장 좋습니다. 이런 방식으로 첫 번째 정규 양식을 충족 하고 데이터베이스 정규화 경로 를 계속 진행할 수 있습니다 .

다른 사람들이 언급했듯이 기본 키가 없어야하는 몇 가지 이유가 있지만 기본 키가 있으면 대부분 피해를받지 않습니다.

기본 키가없는 테이블을 만들 때마다 거의 필요하지 않다고 생각하고 다시 돌아가서 추가했습니다. 이제 기본 키로 사용하는 자동 생성 ID 필드를 사용하여 조인 테이블도 만듭니다.

매우 드문 경우 (다 대다 관계 테이블 또는 대량의 데이터를 대량로드하는 데 임시로 사용하는 테이블)를 제외하고는 다음과 같이 말합니다.

기본 키가 없으면 테이블이 아닙니다!

마크

그냥 추가하면 나중에 선택하지 않았을 때 죄송합니다 (선택, 삭제, 연결 등).

이 테이블을 다른 테이블에 조인해야합니까? 레코드를 고유하게 식별 할 수있는 방법이 필요합니까? 대답이 예이면 기본 키가 필요합니다. 데이터가 고객 인 사람의 이름을 가진 고객 테이블과 같은 것으로 가정하십시오. 이 Sally Smith가 Sally Smith와 다른지 여부를 판별하기 위해 주소, 이메일, 전화 번호 등이 필요하기 때문에 자연 키가 없을 수 있습니다. 사람이 여러 전화를 가질 수 있으므로 주소를 관련 테이블에 저장합니다. , 이메일 등 Sally Smith가 John Jones와 결혼하여 Sally Jones가된다고 가정합니다. 테이블에 인공 키가 없으면 이름을 업데이트 할 때 7 명의 Sally Smiths가 Sally Jones로 변경되었지만 그 중 하나만 결혼하여 이름을 변경 한 경우에도 마찬가지입니다.

당신은 당신이 자연적인 열쇠가 없다고 말하고, 따라서 당신은 독창성을 만들기 위해 어떤 분야의 조합도 가지고 있지 않습니다, 이것은 인공적인 열쇠를 중요하게 만듭니다.

자연 키가없는 경우 언제든지 데이터 무결성을 유지하기위한 필수 키가 필요합니다. 자연 키가 있으면 키 필드로 대신 사용할 수 있습니다. 그러나 개인적으로 자연 키가 한 분야가 아니라면 나는 여전히 자연 키에 대한 인공 키와 고유 인덱스를 선호합니다. 나중에 넣지 않으면 후회하게됩니다.

모든 테이블에 PK를 사용하는 것이 좋지만 반드시 그런 것은 아닙니다. 대부분의 경우 필요에 따라 고유 인덱스 및 / 또는 클러스터형 인덱스 (PK인지 여부)가 필요할 것입니다.

온라인 설명서 (SQL Server 용)의 기본 키 및 클러스터형 인덱스 섹션을 확인하십시오.

" PRIMARY KEY 제약 조건은 테이블의 행을 고유하게 식별하는 값이있는 열 또는 열 집합을 식별합니다. 테이블의 두 행은 동일한 기본 키 값을 가질 수 없습니다. 기본 키의 열에는 NULL을 입력 할 수 없습니다. 작은 정수 열을 기본 키로 사용하는 것이 좋습니다. 각 테이블에는 기본 키가 있어야합니다. 기본 키 값으로 적합한 열 또는 열의 조합을 후보 키라고합니다. "

그러나 다음도 확인하십시오 : http://www.aisintl.com/case/primary_and_foreign_key.html

제안 된 답변에 동의하지 않습니다. 짧은 대답은 NO 입니다.

기본 키의 목적은 다른 테이블과의 관계를 형성하기 위해 테이블에서 행을 고유하게 식별하는 것입니다. 일반적으로 자동 증분 정수 값이이 목적으로 사용되지만 이에 대한 변형이 있습니다.

예를 들어 시계열 데이터 로깅과 같은 경우가 있습니다. 이러한 키의 존재가 단순히 필요하지 않고 메모리를 차지하는 경우도 있습니다. 행을 고유하게 만드는 것은 단순히 ... 필요하지 않습니다!

작은 예 : 표 A : LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

기본 키가 필요하지 않습니다.

표 B : 사용자

Columns: Id, FirstName, LastName etc. 

LogData 테이블에 대한 "외부 키"로 사용 되려면 기본 키 (Id)가 필요합니다.

.NET에서 gridview의 특정 기능을 사용하려면 gridview가 어떤 행을 업데이트 / 삭제 해야하는지 알기 위해서는 기본 키가 필요하다는 것을 알고 있습니다. 일반적으로 기본 키 또는 기본 키 클러스터가 있어야합니다. 나는 개인적으로 전자를 선호합니다.

미래의 증거가되기 위해서는 정말로해야합니다. 복제하려면 하나가 필요합니다. 다른 테이블에 합류하고 싶다면 내 인생과 내년에 그것을 유지 해야하는 가난한 바보의 삶이 훨씬 쉬워 질 것입니다.

저는 해외 개발 팀이 만든 응용 프로그램을 유지 관리하는 역할을 수행하고 있습니다. 원래 데이터베이스 스키마에 일부 테이블의 PRIMARY KEYS가 포함되어 있지 않으므로 응용 프로그램에서 모든 종류의 문제가 발생합니다. 따라서 디자인이 좋지 않아 다른 사람들이 고통을 겪지 않도록하십시오. 항상 테이블에 기본 키를 두는 것이 좋습니다.

처음에는 아직 목표가없는 경우에도 항상 기본 키가 있습니다. PK가없는 테이블에 결국 PK가 필요할 때가 몇 번 있었으며 나중에 PK를 넣는 것이 항상 더 문제가됩니다. 나는 항상 하나를 포함시키는 것에 대한 더 큰 단점이 있다고 생각합니다.

요컨대 그러나 특정 클라이언트 액세스 CRUD 조작에 필요하다는 점을 명심해야합니다. 향후 교정을 위해 항상 기본 키를 사용하는 경향이 있습니다.

최대 절전 모드를 사용하는 경우 기본 키없이 엔티티를 작성할 수 없습니다. 일반 sql / ddl 스크립트로 작성된 기존 데이터베이스로 작업 중이고 기본 키가 추가되지 않은 경우이 문제로 인해 문제점이 발생할 수 있습니다.