web-dev-qa-db-ja.com

多対多のテーブルに主キーが必要ですか?

多対多の関係にある2つのオブジェクトがある場合、通常は、2つを関連付けるために、多対多のテーブルを使用してデータベーススキーマでそれらをモデル化します。しかし、その多対多のテーブル(または「結合テーブル」)には、独自の主キー(整数の自動インクリメント)が必要ですか?

たとえば、それぞれIDを持つテーブルAとBと、(A_ID、B_ID)の外部キータプルを持つA_Bというテーブルがあるとします。しかし、A_Bには独自の主キー自動インクリメントID列が必要ですか?

それを追加することの長所と短所は何ですか?私は個人的に、多対多の結合のための自然キーが好きです。しかし、主キーはどのような追加の利点を追加しますか?

29
ashes999

Odedが言ったことを除いてすべてに同意します

「外部キーとしても合理的に使用することはできません。」

この場合、それはあなたの毒を選ぶことです、マッピングテーブルは絶対に親になることができます、それは複数列のFKを使用するかどうかの子の問題です。

車と色の簡単なケースを取ります。毎年、自動車メーカーには特定の色のパレットがあり、各モデルには限られた数の色しかありません。多く-多く::車のモデルへの色

そこで、新車の注文が保存される注文テーブルを設計します。明らかに色とモデルは注文テーブルにあります。これらの各テーブルにFKを作成すると、データベースは誤ったモデル/色の組み合わせを選択することを許可します。 (もちろん、これをコードで強制することはできますが、宣言的に行うことはできません。)親をmany:manyテーブルにすると、指定された組み合わせのみが取得されます。

したがって、複数列のFKを使用して、ModelIDとColorIDの両方で構築されたPKを指すようにしますか、それとも単一列のFKが必要ですか?

あなたの毒を選んでください。

編集

ただし、それが何かの親でない場合、代理キーを必要とするテーブルはありません。

19
Stephanie Page

このような代理キーは、オーバーヘッド以外には何も追加しません。

この表での重複が気になる場合は、自然キーを使用し、それらを複合主キーにします。

拡大するために:

アプリケーションでは、このキーは無意味になり、未使用のままになります。

データベースでは、意味のある結果のクエリで合理的に使用できないため、機能はありません。

外部キーとしても合理的に使用することはできません。

11
Oded

私はそれを両方の方法で行いました。将来的に機能を追加するのに役立つ場合があります。たとえば、テーブルの行に2つのID以外のものが含まれることがあったとします。スペースが足りないのなら、痛くないからといってそこに入れておきます。 hibernateやADO.NETなどのORMツールに干渉する場合がありますが、それは軽微です。

要約すると...長所1.潜在的な将来の成長を可能にします。

短所1.スペース2.いくつかのORMツールを混乱させます。

1
dko

「結合テーブル」という用語はよく使用されますが、適切に定義または説明されているのを見たことがないと思います。個人的にはその用語の使用は避けています。私が理解しているように、「結合テーブル」とは、2つの外部キー(または2つ以上?)を持つテーブルを意味します。

複数の外部キーを持つテーブルでキーを選択するための基準は、他のテーブルとほとんど同じである必要があると思います。強制する必要のある依存関係、一意で既約なものを自問してください。習熟度、安定性、シンプルさの基準でキーを選択します。正当な理由がある場合にのみ、代理キーを追加してください。

1
nvogel

それは本当に有用なものを提供しません。キーの目的は、「何か」を一意に参照することであることに注意してください。このような関連付けテーブルは、それ自体が「何か」ではなく、すでにキーを持っている他の2つの「何か」の永続構造です。永続性メディア(データベース)の外部では、それは意味を持たず、実際に存在したり、(ビジネスドメインなどで)知られているべきではないため、によって参照する理由はありません(すべきではありません)。独自のID。

0
David