database - Natural ID で関係を作成したり、内部 ID を使用して Natural ID 関係をエミュレートしたりすることはありますか?

Question

重複の可能性:
サロゲート対。自然/ビジネスキー

2 つのテーブルが与えられた場合、レベル 1 [ID、タイトル、番号] レベル 2 [ID、FKID???、タイトル、番号]

システムのユーザーは、レベル 2 がレベル 1 の番号に基づいてレベル 1 に関連付けられていることを理解しています。私の質問は、内部 ID に基づいて関係を作成し、「番号」との関係を「エミュレート」しますか、それとも単に「数字」フィールドとそれで終わりですか？

score 3 · Accepted Answer

自然 ID ではなくデータベース ID に関連付ける 2 つの標準的な理由は次のとおりです。

どのような状況でも自然 ID が変更されないことを保証することは困難です。
一般に、自然 ID はより多くのスペースを必要とし、データベース ID ほど効率的にインデックスを作成することはできません (もちろん、これは困難でも高速でもありません。自然 ID を構成するデータによって異なります)。データベースIDを利用することで、業務データの重複を避けることができます。

score 2 · Accepted Answer

この議論はあちこちで殴り殺されました。自然キーのみを擁護する人はほとんどおらず、ほとんどの人は代理キーの使用を推奨しています。もちろん、両方を持つことができると言う人もいますが、これは本当です (ビジネスルールが適用されるように自然キーを使用してください)。

自然キーが本当にキーであるかどうか、私は二度考えがちです (ほとんどの場合、そうではありません)。もしそうなら、私はそれを使います。

しかし、繰り返しになりますが、実際にはほとんどの自然キーはキーではなく、さまざまな理由で重複があります。たとえば、国民 ID カードが発行されている国では、同じ ID 番号を持つ人が 2 人いることは珍しくありません。

つまり、代理キールートを使用する場合は、次のようにテーブルを設定します。

Level1 [ID、タイトル、番号] Level2 [ID、FKID は Level1 を参照]

タイトルと番号を 2 回保存する必要はありません。

score 0 · Accepted Answer

これは何度も取り上げられていると思います。

ほとんどの場合、IDENTITY/AUTONUMBER を外部キーとして使用する方が安全です。

ほとんどの自然キーは (エラーであっても) 複製できます。

私の国では、人々の個人 ID 番号にも問題があります X-)。

score 0 · Accepted Answer

「数値」列を使用して 2 つのテーブルを自然な方法で関連付けることができる場合、内部 (代理) キーに基づいて関係を強制することはありません。

一方では、'Number' 列で十分な場合があるため、ID 列でスペースを無駄にすることはありません。一方、「Number」列に適切な特性がない場合 (変更される可能性がある、インデックスが作成しにくいなど)、代理 ID の方が適切なオプションである可能性があります。

それはすべて「数値」列のセマンティクスに要約されます。

score 0 · Accepted Answer

キーの安定性が保証されている場合( SSN や従業員 ID など) は、自然キーを使用するのが最適な場合があります。
代理キーの場合、FK は基本的に、あるシステムで生成された # から別のシステムで生成された # への関係です。極端な場合、そのような人為的な関係は現実と完全に一致しない可能性があります。
他の投稿者は、自然キーを変更する必要があるときに発生する混乱についてコメントしています。確かにそれは問題です。しかし、これらの例外がどのくらいの頻度で発生するかを調べる価値があります-すべての場合で、尻尾 (例外) が犬 (あなたのデザイン) を振る必要がありますか?
私はこれについて熱狂的ではありませんが、自然キーと代理キーが混在する同じデータベース内で異なる規則を持つことは不便であることに同意します。
自然キーが複数のフィールドである場合、たとえば DateOfBirth + LastName + Department (またはそのような奇妙なもの) の場合は、人工キーを使用することをお勧めします。

上記のすべての引数は、データモデルの論理レベルにあります。物理レベルでは、状況、サーバー、およびパフォーマンスの制約によって決定が決まります。時期尚早に最適化しないことが最善です。

5 に答える 5