私は2つのテーブルを持っています、テーブルAとテーブルBと呼ばれるとしましょう。テーブルBからのアイテムはAの複数のインスタンスに存在することができ、それぞれAは複数のBを含むことができます。それらの主キーによって。私の質問は、私はこの関連テーブルを定義するとき、私は関連テーブルに主キーを持っている必要がありますか？それとも必要ないのですか？ TDWTFを終わらせるのをやめようとしているだけです:)RDBMSのベストプラクティス - 関連テーブルの自動作成？
主キーは、関連テーブルのテーブルA PK列とテーブルB PK列にあります。そうすれば、偶然、関連テーブルに重複行がないようにすることができます。
主キーの主な目的の1つは、参照整合性を保証することです。つまり、重複しないでテーブルのデータをきれいに保ちます。この場合のPKは、アソシエーションテーブルに2つの重複した行がないことを保証します。
不要です。どちらのキーも、関連テーブルの主キーを形成する必要があります。双方向ナビゲーションを行う場合は、キーを逆にしたインデックスを追加することを検討してください。
常にプライマリキーが必要です。
しかし、私はそれがどうなるべきかによって異なります。何らかの種類のORMシステム（例えばHibernate）を使用する場合は、代理識別子を持つことが最善で、2つの外部キー（テーブルAとBを指す）は一意のインデックスを形成する必要があります。
また、このような関係を別のテーブルから参照する必要がある場合は、この代理識別子を使用すると便利です。
あなたの意図を示すために主キーを使用したいと思うかもしれません。例えば、
a、b
aa、b
とすると、A.aとB.bで定義されているプライマリキーを使用すると、より明確になります。気にしないが、a、bなどのフィールドがある場合は、代理キーをプライマリ・キーとして追加すると、不要な行を一様に削除するのに役立ちます。それ以外の場合は、a = aとb = bを削除し、??削除する行からフィールド値を選択します。一方、代理キーを使用すると、行を選択してmykey = 36か何かを削除することができます...
実際にはビジネスケースによって異なります。多くの交差テーブルには、ある種の日付範囲、または2つのテーブルのキーに加えて関係に関連する追加フィールドがあります。既存の列、新しい代理キー、独自の索引、制約、索引のない主キーを定義することは、必要に応じてすべて有効なアクション・コースとなります。
私は間違いなくあなたの意図を最も明瞭にすると言います。