複合キーを別のテーブルの主キーとして設定できますか?
たとえば、私はテーブルを持っています：
Books - 主キーあり:Product_IDClient-主キーあり:Client_IDClients_Books-複合主キーを使用:Product_IdおよびClient_IDこの複合主キーを Clients_Books から主キーとして、Order_Details という名前の別のテーブルに設定したいと考えています。しかし、Books、Clients テーブルの Product_ID と Client_ID は使用したくありません。
これは理にかなっていますか？すべての意見は大歓迎です。
あなたは暗く汚い道を歩いています。これをしないでください。ベスト プラクティスに従ってください。テーブルで単純な主キーを使用し、必要に応じて他のテーブルへの外部キーを使用します。
簡単に言えば、いいえ、それはできません。PK (または他の代替キー) のすべての列が FK 定義に含まれている必要があります。また、テーブルには複数のキーを含めることができることに注意してください。これは、候補キー (代替キーの場合もあります) と呼ばれます。主キーは、単に設計/使用に「最適な」キーです (通常、最も狭いキー - バイト サイズが最小)。これらの他の一意のインデックスの名前の前に「AK_{name}」（AK = 代替キー）を付けます。
この状況下で私たちが行うことは、次の 2 つのいずれかです。
一般に、同じ PK 定義を持つ複数のテーブル (つまり、別のテーブルへの FK でもある PK) を持つことはお勧めできません。「一般的に」と言いますが、エンティティの定義を理解することが重要です。
では、なぜ #1 を使用するのでしょうか。私が自問するのは、複合キーが実際に行を定義するデータであるかどうかということです。その複合キーは本当に行の定義ですか、それとも他のデータへの FK のようなものですか? それが FK に近い場合は、合成された PK(Identity) を作成します。注文は本当にクライアントが所有する書籍ですか? 注文により、クライアントは新しい本を所有するようになる場合がありますが、それらは同じものではない場合があります。
合成された PK を持つことで、将来的にいくつかの選択肢が提供されます。Client_Books テーブルで関係を変更する必要がある場合は、他のテーブルへの変更を隔離することができます。
たとえば、顧客が 1 冊の本を複数所有できる場合、それをどのように実装しますか? 合成キーを使用すると、単純に複合キーの Unique インデックスを削除し、単純な FK として残すことができます。そうすると、Order_Details テーブルは、顧客が 2 番目のコピーを購入した時期を単純に表します。ただし、Orders ルートで複合キーを取得した場合は、Order_Detail と Client_Books (および Order_Detail を指すその他の FK) を再定義する方法を理解する必要があります。
また、Order_Detail が本当に Client_Book であるかどうかを評価してください。通常、注文により、クライアントは新しい本を手に入れることができます。Orders はインベントリから独立していると考えています。したがって、Order_Detail の PK は Client_Books の PK であってはならず、Order_Detail にはおそらく独自の独立した PK が必要です。