代理キー/人工キーの一般的な利点の1つを理解しています。変更されないため、非常に便利です。これは、「人工」である限り、単一フィールドでも複数フィールドでも同じです。
ただし、各テーブルの主キーとして自動インクリメント整数フィールドを持つことはポリシーの問題のように思われる場合があります。これは常にそのような単一フィールドのキーを持っているのが最良のアイデアですか？なぜですか？
明確にするために、この質問は人工対自然に関するものではなく、すべての人工キーを単一フィールドにする必要があるかどうかに関するものです
回答:
私は言うつもりはない常に、いや、しかし時間イエスの最も。。
これらは、代理キーまたは人工キーを必要としないいくつかの状況です。
また、古い忠実な単調増加する整数代理キーが理想的ではない状況もあります。英数字のサロゲートであるキーを持つことができます。これらには以下が含まれます。
なぜほとんどの場合はイエスですか？その質問に対する最も基本的な答えは、テーブルの主キー値を変更する必要がある場合、それは純粋な地獄だということです。以来、ほとんど何もユーザーが見ることができるか、タッチが考えられるいくつかの点で、更新の対象に、純粋な地獄を招いている目に見えるキー値を使用しています。代理キーを使用すると、このトラップに陥ることがなくなります。
そうは言っても、YAGNIにはこの概念を適用する余地があることを忘れないでください。従業員テーブルの男性の性別の記号をMからXまたは愚かなものに変更する必要があると判断した場合に備えて、IDENTITYキーを持つコードテーブルをスキーマの隅々まで強制する必要はありません。
いや
少なくとも外部キーの目的上、単一フィールドキーが複合キーよりも劣る場合は確かにあると思います。それはあなたが望むなら単一フィールドの代理キーも持つべきではないということではありませんが、私は個人的には主キーと呼ばれる外部キーのターゲットとして最も頻繁に使用されるキーを好みます
次の例で私のポイントを説明しようとします。
brand フォード、トヨタなどの自動車ブランドdealer ブランドに関連付けられた物理的なディーラーです（例：フォードのみを販売するフォードディーラー）model フォードフォーカス、フォードフィエスタなどの車のタイプstock 各ディーラーの現在のフォアコートの車の数です我々は、単一のフィールドサロゲートキーを作成した場合のためにdealerとmodel、以下のように：
create table brand( brand_id integer primary key );
create table dealer( dealer_id integer primary key,
brand_id integer references brand )
create table model( model_id integer primary key,
brand_id integer references brand )
create table stock( model_id integer references model,
dealer_id integer references dealer,
quantity integer,
primary key(model_id, dealer_id) )次にstock、Ford dealerを「Toyota」モデルにリンクする行を挿入することができます。追加brand_id references brandしますstockだけで問題が悪化します。一方、外部キーを次のようにプライマリキーの一部として保持する場合：
create table brand( brand_id integer primary key );
create table dealer( brand_id integer references brand,
dealer_id integer,
primary key(brand_id, dealer_id) )
create table model( brand_id integer references brand,
model_id integer,
primary key(brand_id, model_id) )
create table stock( brand_id integer,
model_id integer,
dealer_id integer,
quantity integer,
primary key(brand_id, model_id, dealer_id),
foreign key(brand_id, model_id) references model,
foreign key(brand_id, dealer_id) references dealer )現在、「Ford」ディーラーは「Ford」車のみを在庫できるというルールがモデルによって自然に施行されています。
「複合キー」の例でdealer_idは、好みに応じて一意である場合と一意でない場合があることに注意してください。一意である必要はありません（つまり、代替キー）が、そうすることによって失われることはほとんどなく（おそらく少しのストレージスペース）、非常に便利になる可能性があるので、通常は次のように設定します。
create table dealer( brand_id integer references brand,
dealer_id serial unique,
primary key(brand_id, dealer_id) )"場合によります"
はい：サロゲートIDENTITY / AUTONUMBERフィールドは、自然キーが広く非数値の場合に適しています。注：これは、「PK」とSQL ServerおよびSybaseなどでデフォルトで発生するクラスター化インデックスの融合を前提としています。
いいえ：2つの親キーで十分な場合、多数/多数のテーブル。または、自然キーが短く固定長の場合（通貨コードなど）
もちろん、ブレインデッドORM（読む：（n）Hibernate）はこれらのルールに勝つかもしれません...
編集：質問をもう一度読む
2つの代理親キーを持つ多/多テーブルには、複数列PKがあります。
ただし、別のサロゲート列は必要ありません。
テーブルにサロゲート（IDENTITYなど）キーがある場合、複数の列である必要はありません。
サロゲートを含むスーパーキーを持つことができますが、これは他のルール（サブタイプなど）を実施するためです