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