複合主キーと追加の「ID」列
このようなテーブルがある場合：
書籍（「ISBN」が存在しないふりをする）
- 著者
- 題名
- 版
- 発行年
- 価格
{Author、Title、Edition}が候補/主キーになる可能性があると主張できます。
候補/プライマリキーを{Author、Title、Edition}にする必要があるのか、または{Author、Title、Edition}に一意のインデックス/キー制約を指定してID列を使用するのかを決定するものは何ですか？
そうです
- 著者（PK）
- タイトル（PK）
- エディション（PK）
- 発行年
- 価格
より良い、または：
- ID（PK）
- 著者
- 題名
- 版
- 発行年
- 価格
{Author、Title、Edition}は追加の一意のインデックス/制約ですか？
一般に、主キーの値を変更することは望ましくありません。これが、ブラインドまたはサロゲート主キーが使用される理由です。
主キーの一部としてAuthorでBookテーブルを作成したと仮定しましょう。
約1年後に「Ray Bradbury」のスペルを間違えたことがわかったとします。さらに悪いことに、「レイチェルブルーム」のスペルを間違えました。スペルミスを修正するために修正する必要があるデータベース行の数を想像してください。変更する必要があるインデックス参照の数を想像してください。
ただし、代理キーを持つAuthorテーブルがある場合、修正する必要があるのは1行だけです。インデックスを変更する必要はありません。
最後に、データベーステーブル名は通常、複数形（ブック）ではなく単数形（ブック）です。
代理主キーシナリオを使用するもう1つの理由は、一意性制約が将来変更される場合です（たとえば、ISBNを追加して書籍を一意にする必要がある場合）。データのキーの再生成がはるかに簡単になります。
これに関連する多くの記事があります。あなたの場合の複合キーの問題：
- 本を他のエンティティとリンクするのが難しい
- ほとんどのグリッドは複合キーをサポートしていないため、グリッドで編集するのは困難です（例：剣道グリッド、jqgrid）
- 著者、タイトル、エディションのスペルを間違える可能性があります
データを正規化し、提案された（dasblinkenlight）のような作成者にIDだけを保存することも良いでしょう。最悪のシナリオ、彼/彼女は彼/彼女の名前を変更します（例えば、彼女は結婚し、彼女は彼女の新しい名前が好きです）。