tsql - 複合主キーを持つことの長所と短所

Question

複合主キー（このテーブルは2つのエンティティ[2つのテーブル]を表す2つのテーブル間の関係を維持します）を持つ代わりに、identity主キーとして列を持つように設計が提案され、一意のデータ制約が2つの列に適用されます。エンティティの主キーからのデータ。

私にとって、関係テーブルごとにID列があると、正規化ルールに違反します。

• 業界標準とは何ですか？
• これについて設計を決定する前に考慮すべきことは何ですか？
• どちらのアプローチが正しいですか？

Answer 1

主キーとしてID列を使用したいテーブルはたくさんあります。ただし、説明するM：M関係テーブルの場合、ベストプラクティスは、主キーに新しいID列を使用しないことです。

コメント内のRThomasのリンクは、ベストプラクティスがID列を追加しないことであるという優れた理由を提供します。これがそのリンクです。

短所はほとんどすべての場合に長所を上回りますが、長所と短所を求めたので、私はいくつかのありそうもない長所も入れました。

短所

• 複雑さを追加します

• 関係に一意性を強制しない限り、関係が重複する可能性があります（主キーがデフォルトで実行します）。

• おそらく遅い：dbは1つではなく2つのインデックスを維持する必要があります。

長所

すべてのプロはかなり大ざっぱです

• リレーションシップテーブルの主キーを別のテーブル（監査テーブルなど）への結合として使用する必要がある状況では、結合が高速になる可能性があります。（ただし、前述のように、レコードの追加と削除は遅くなる可能性があります。さらに、リレーションシップテーブル自体が一意のIDを使用するテーブル間のリレーションシップである場合、結合で1つのID列を使用することによる速度の向上は最小限に抑えられます。）

• アプリケーションは、簡単にするために、動作するすべてのテーブルが主キーとして一意のIDを持っていると想定する場合があります。（これはアプリの設計が貧弱ですが、制御できない場合があります。）このようなアプリに余分な複雑さを導入するよりも、DBに余分な複雑さを導入する方がよいシナリオを想像できます。

Answer 2

外部キーとして使用される場合は常に、各テーブルにすべての列を作成する必要があります。これが最大の欠点です。

Answer 3

短所：

• 複合主キーは、すべての参照テーブルにインポートする必要があります。これは、インデックスが大きくなり、書き込むコードが増えることを意味します（たとえば、結合、更新）。複合主キーの使用について体系的である場合、それは非常に面倒になる可能性があります。
• 主キーの一部を更新することはできません。たとえば、university_id、student_idを大学生のテーブルの主キーとして使用し、1人の学生が大学を変更した場合、レコードを削除して再作成する必要があります。

長所：

• 複合主キーを使用すると、一般的な種類の制約を強力で見かけのない方法で適用できます。テーブルUNIVERSITY、テーブルSTUDENT、テーブルCOURSE、およびテーブルSTUDENT_COURSE（どの学生がどのコースをフォローするか）があるとします。大学Aのコースを受講するには、常に大学Aの学生である必要があるという制約がある場合、university_idがSTUDENTとCOURSEの両方の複合キーの一部である場合、その制約は自動的に検証されます。