모든 테이블에 기본 키가 있어야 합니까?

모든 테이블에 기본 키가 있어야 합니까?

데이터베이스 테이블을 만들고 있는데 논리적 기본 키가 할당되어 있지 않습니다.모든 테이블에 기본 키가 있어야 합니까?

단답: 네.

긴 답변:

• 당신의 테이블이 무언가에 참여할 수 있어야 합니다.
• 테이블을 클러스터링하려면 기본 키 같은 것이 필요합니다.
• 테이블 설계에 기본 키가 필요 없는 경우 설계를 다시 생각해 보십시오. 아마도 무언가가 누락되어 있을 것입니다.왜 똑같은 기록을 유지하는 거지?

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

기본 키는 합성할 수 있습니다.

다대다 링크 테이블이 있는 경우 링크에 포함된 모든 필드에 기본 키를 만듭니다.따라서 하나의 링크를 설명하는 두 개 이상의 레코드를 갖지 않도록 해야 합니다.

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

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

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

• 인덱스를 고유하게 만들기

추신: 기본 키가 필요 없는 아주 아주 특별한 경우도 있습니다.

대부분은 성능상의 이유로 인덱스가 없는 로그 테이블을 포함합니다.

항상 기본 키를 갖는 것이 가장 좋습니다.이렇게 하면 첫 번째 정규 양식을 충족하고 데이터베이스 정규화 경로를 따라 계속 진행할 수 있습니다.

다른 사람들이 말한 것처럼, 기본 키를 가지고 있지 않을 이유가 있지만, 기본 키가 있다면 대부분 피해를 입지 않을 것입니다.

제안된 답변에 동의하지 않습니다.단답형은 아니오 입니다.

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

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

작은 예로 다음과 같습니다.표 A: 로그 데이터

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

기본 키가 필요 없습니다.

표 B: 사용자

Columns: Id, FirstName, LastName etc. 

LogData 테이블에 대한 "외래 키"로 사용하기 위해서는 Primary Key(Id)가 필요합니다.

매우 드문 몇 가지 사례(다대다 관계 테이블 또는 일시적으로 엄청난 양의 데이터를 대량으로 로드하는 데 사용하는 테이블)를 제외하고는 다음과 같이 말합니다.

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

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

추가만 해주시면 나중에 (선택, 삭제) 죄송합니다.링크 등)

이 테이블을 다른 테이블과 합칠 필요가 있습니까?기록을 고유하게 식별할 수 있는 방법이 필요합니까?대답이 yes이면 기본 키가 필요합니다.데이터가 고객인 사람들의 이름이 있는 고객 테이블과 같은 것이라고 가정합니다.주소, 이메일, 전화번호 등이 샐리 스미스와 다른지 판단하기 위해 필요하기 때문에 자연스러운 키가 없을 수도 있습니다. 그리고 그 사람이 여러 개의 전화기, 주소, 이메일 등을 가질 수 있기 때문에 관련 테이블에 그 정보를 저장하게 됩니다.샐리 스미스가 존 존스와 결혼해서 샐리 존스가 된다고 가정해 보겠습니다.테이블 위에 인공 키가 없다면 이름을 업데이트할 때 샐리 스미스 7명을 샐리 존스로 바꿨습니다. 그들 중 한 명만 결혼해서 이름을 바꿨는데도 말이죠.그리고 물론 인공 열쇠가 없는 이 경우에는 어떤 샐리 스미스가 시카고에 살고 어떤 사람이 LA에 살고 있는지 어떻게 알 수 있습니까?

고유한 키가 없으므로 고유한 필드 조합도 없다고 하면 인공 키가 중요합니다.

저는 자연 키가 없을 때마다 인공 키가 데이터 무결성을 유지하는 데 절대적으로 필요하다는 것을 알게 되었습니다.자연 키가 있는 경우 대신 키 필드로 사용할 수 있습니다.하지만 개인적으로 자연 키가 한 분야가 아닌 이상, 저는 여전히 자연 키의 인공 키와 고유 색인을 선호합니다.안 넣으면 나중에 후회할 거예요.

모든 테이블에 PK를 사용하는 것이 좋지만 MUST는 아닙니다. 필요에 따라 고유한 인덱스 및/또는 클러스터된 인덱스(PK 여부)가 필요할 수 있습니다.

Books Online(SQL Server용)의 Primary Keys(기본 키) 및 Clustered Index(클러스터된 인덱스) 섹션을 확인합니다.

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

하지만 이것 또한 확인해보세요: http://www.aisintl.com/case/primary_and_foreign_key.html

파티에 늦었지만 2센트를 추가하고 싶었습니다.

모든 테이블에 기본 키가 있어야 합니까?

• "Relational Albegra"를 말하는 것이라면, 대답은 "Yes"입니다.이러한 방식으로 데이터를 모델링하려면 엔티티와 테이블에 기본 키가 필요합니다.관계 대수학의 문제점은 (그것의 맛이 20가지나 된다는 사실을 제외하고) 종이에만 존재한다는 것입니다.관계 대수를 사용해서 실제 응용 프로그램을 만들 수는 없습니다.

• 자, 만약 여러분이 실제 앱의 데이터베이스에 대해 이야기한다면, 그것들은 부분적으로/대부분은 그것의 최선을 다함으로써, 그리고 그것의 다른 부분들을 간과함으로써, 관계 대수학을 고수합니다.또한 데이터베이스 엔진은 현재 대규모의 관계형이 아닌 기능을 제공합니다(2020년 현재).그래서 이 경우 답은 아니오입니다.어쨌든 실제 세계 테이블의 99.9%가 기본 키를 가지고 있지만 정당한 예외도 있습니다.대표적인 사례: 이벤트/로그 테이블(여러 인덱스가 있지만 키가 하나도 보이지 않음).

결론적으로, 개체/관계 모델을 따르는 트랜잭션 응용프로그램에서는 거의 모든 테이블(그렇지 않을 경우)에 기본 키를 갖는 것이 타당합니다.테이블의 기본 키를 건너뛰기로 결정한 경우, 테이블에 대한 적절한 이유가 있는지 확인하고 결정을 방어할 준비가 되어 있습니다.

미래의 증거로 만들기 위해서는 당신이 정말로 해야 합니다.복제하려면 복제가 필요합니다.만약 여러분이 다른 테이블에 합류하고 싶다면, 여러분의 삶(그리고 내년에 그것을 유지해야 하는 가난한 바보들의 삶)은 훨씬 쉬워질 것입니다.

저는 해외 개발팀에서 만든 애플리케이션을 유지하는 역할을 하고 있습니다.원래 데이터베이스 스키마에 일부 테이블에 기본 키가 포함되어 있지 않아 응용 프로그램에서 모든 문제가 발생하고 있습니다.그러니 당신의 서투른 디자인 때문에 다른 사람들이 피해를 보지 않도록 해주세요.테이블 위에 기본 키를 두는 것은 항상 좋은 생각입니다.

15.6.2.1 Clustered and Secondary Indexs - MySQL과 같은 공식적인 것을 찾고 싶습니다.

테이블에 PRIMARY KEY 또는 적절한 UNIQUE 인덱스가 없는 경우 InnoDB는 내부적으로 행 ID 값이 포함된 합성 열에 GEN_CLUST_INDEX라는 숨겨진 클러스터 인덱스를 생성합니다.행은 InnoDB가 이러한 테이블의 행에 할당하는 ID에 따라 순서가 정해집니다.행 ID는 6바이트 필드로 새 행이 삽입되면 단조롭게 증가합니다.따라서 행 ID로 정렬된 행은 물리적으로 삽입 순서가 됩니다.

그렇다면 기본 키 같은 것을 직접 만들어 보는 것은 어떨까요?또한 ORM은 숨겨진 ID를 식별할 수 없으므로 코드에 ID를 사용할 수 없습니다.

의 그리드 뷰의 특정 기능을 사용하기 위해 알고 있습니다.NET, 그리드 보기에서 업데이트/삭제가 필요한 행을 파악하려면 기본 키가 필요합니다.일반적인 관례는 기본 키 또는 기본 키 클러스터를 갖는 것이어야 합니다.저는 개인적으로 전자가 더 좋습니다.

저는 처음에 그것에 대한 목적이 아직 없더라도 항상 기본적인 열쇠를 가지고 있습니다.PK가 없는 테이블에 결국 PK가 필요한 경우가 몇 번 있었는데 나중에 넣는 것이 항상 더 곤란합니다.저는 항상 그것을 포함하는 것이 더 좋은 점이라고 생각합니다.

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

한마디로 안 돼요.그러나 특정 클라이언트 액세스 CRUD 작업에는 CRUD 작업이 필요합니다.저는 향후 교정을 위해 항상 기본 키를 사용하는 편입니다.

기본 키가 없는 테이블을 정의하면 테이블에 클러스터된 인덱스가 없다는 것을 의미합니다.이러한 테이블을 힙 테이블(heap table)이라고 하며, 클러스터 인덱스를 유지할 걱정 없이 테이블에 쓰기를 효율적으로 수행할 수 있습니다.

언급URL : https://stackoverflow.com/questions/840162/should-each-and-every-table-have-a-primary-key