多対多の関係を持つ 2 つのオブジェクトがある場合、通常はデータベース スキーマでそれらをモデル化し、多対多のテーブルを使用して 2 つを関連付けます。しかし、その多対多テーブル (または「結合テーブル」) には、独自の主キー (整数自動インクリメント) が必要ですか?
たとえば、それぞれ ID を持つテーブル A と B と、(A_ID, B_ID) の外部キー タプルを持つ A_B というテーブルがあるとします。しかし、A_B には、独自の主キーの自動インクリメント ID 列が必要ですか?
追加するメリットとデメリットは？私は個人的に、多対多結合の自然キーが好きです。しかし、主キーによってどのような利点が追加されるのでしょうか?
私はオデッドが言ったことに同意します。
「外部キーとしても合理的に使用できません。」
この場合、それはあなたの毒を選ぶことです。マッピングテーブルは絶対に親になることができます。それは、子が複数列の FK を使用するかどうかの問題です。
Car と color の単純なケースを取り上げます。毎年、自動車メーカーには特定の色のパレットがあり、各モデルにはこれらの色の限られた数しかありません。多くの - 多くの :: 色から車のモデル
そこで、新しい車の注文が格納される Order テーブルを設計します。明らかに、色とモデルが注文テーブルに表示されます。これらのテーブルのそれぞれに FK を作成すると、データベースは誤ったモデル/色の組み合わせの選択を許可します。(もちろん、これをコードで強制することはできますが、宣言的に行うことはできません。) 親を多対多テーブルにすると、指定された組み合わせのみが取得されます。
SO では、複数列の FK を使用して、ModelID と ColorID の両方で構築された PK をポイントしますか?それとも単一列の FK が必要ですか?
あなたの毒を選んでください。
編集
ただし、それが何かの親でない場合、テーブルに代理キーは必要ありません。
このような代理キーは、オーバーヘッド以外には何も追加しません。
このテーブルでの重複が気になる場合は、自然キーを使用し、それらを複合主キーにします。
拡大するために：
アプリケーションでは、このキーは意味がなく、使用されません。
データベースでは、意味のある結果を求めるクエリで合理的に使用できないため、機能はありません。
また、外部キーとして合理的に使用することもできません。
私はそれを両方の方法で行いました。将来的に機能を追加するのに役立つ場合があります。たとえば、テーブルの行に 2 つの ID 以外のものが含まれる場合があります。スペースが不足していない場合は、傷つかないという理由だけでそこに置きます. 休止状態や ADO.NET などの ORM ツールに干渉することもありますが、それは軽微です。
要約すると... 長所 1. 潜在的な将来の成長を可能にします。
短所 1. スペース 2. 一部の ORM ツールを混乱させます。
「結合テーブル」という用語はよく使用されますが、適切に定義または説明されているのを見たことがないと思います。個人的には、その用語を使用することは避けています。私が理解しているように、「結合テーブル」とは、2 つの外部キー (または 2 つ以上) を持つテーブルを意味します。
複数の外部キーを持つテーブルでキーを選択するための基準は、他のテーブルとほぼ同じであるべきだと思います。どの依存関係を強制する必要があるか、何がユニークで還元不可能かを自問してください。親しみやすさ、安定性、シンプルさの基準でキーを選択します。正当な理由がある場合にのみ代理キーを追加してください。
それは本当に有用なものを提供しません。「何か」を一意に参照するというキーの目的を念頭に置いてください。このような関連テーブルは、それ自体では「何か」ではなく、すでにキーを持っている他の 2 つの「何か」の永続構造です。持続性媒体 (データベース) の外では意味がなく、(ビジネス ドメインなどで) 実際に存在したり、知られたりするべきではありません。独自のID。