「新しい」アプリケーションでは、複合キーを考慮しないでください。過去には、「ビジネスキー」は「代理キー」よりも優れていると考えていた人々によって使用されていました。
編集：クリスからの質問に応じて、答えを広げています。
まず、この質問を「複合主キー」と「代理キー」として理解していることを述べておきます。
また、1つあることを認めます 複合キーが理にかなっているユースケース：「リンクテーブル」とも呼ばれる相互参照テーブル。これらは多対多のテーブルで使用され、2つのフィールドのみで構成されます。どちらのフィールドも、外部参照テーブルの主キーを形成する外部キーです。たとえば、UserRole テーブルにはuser_idが含まれます およびrole_id 、他には何もありません。たとえば、このようなテーブルの場合、Javaにはクラス表現はありません。これは通常、@ManyToManyです。 、Collection 両側に。
別の回答で、自然キーと代理キーについての意見を共有しました（ Hibernate：コンポジットPKとサロゲートPKの意見 ）、そして私は、Compositeキーは、実際のメリットをもたらすことなく、Naturalキーのいくつかの欠点を共有していると信じています。
複合キーの問題は、2つが必要になることです。 レコードを一意に識別するための値。これは、この最初のテーブルのレコードを参照するテーブルを作成し始めると問題になります。次に、2番目のテーブルには2つが必要です。 1つを参照できる列 記録。そして、この2番目のテーブルが単一の値と外部キーで構成される複合キーを使用している場合、3つになります。 1つを一意に識別する列 記録。そして、3番目のテーブルにはこれらの 3 が必要です 1つを参照するための追加の列 2番目のテーブルに記録します。ほんと、これは雪玉です。
もう1つの欠点は、要件が実行されることです。 変化する。いつも。したがって、今日は優れた複合キーと思われるものが、明日はまったくキーではありません。そのため、代理キーがあります。将来を見据えたものにするためです。
複合キーは主に、テーブル内のレコードが一連の列に基づいて一意になるように使用されます。たとえば、Customersがある場合 テーブルには、NationalIdがある場合があります +Country 一意の値として。つまり、国が米国の場合、2人のユーザーが同じSSNを共有することはできません。ただし、同じ国にない場合は、2つのレコードに同じ番号を付けることができます。複合キーが好きな場合は、これが適しています。ただし、前に示唆したように、代理キーを使用してuniqueを適用できます。 制約。複合キーの利点に加えて、代理キーの安全性があります。