どちらがベストプラクティスであり、その理由は何ですか？
a）タイプテーブル、サロゲート/人工キー
外部キーはfromuser.typeからtype.id：
b）タイプテーブル、自然キー
外部キーはfromuser.typeからtype.typeName：
3396 次
10 に答える
19
実際には、自然キーを使用することが最善の選択肢になることはめったにないと思います。私はおそらくあなたの最初の例のように代理キーアプローチに行くでしょう。
自然キーアプローチの主な欠点は次のとおりです。
タイプ名が間違っているか、タイプの名前を変更したいだけかもしれません。これを編集するには、外部キーとして使用するすべてのテーブルを更新する必要があります。
フィールドのインデックスは、
intフィールドのインデックスよりもはるかにコンパクトになりvarcharます。場合によっては、一意の自然キーを使用することが難しい場合があります。これは、主キーとして使用されるため、必要になります。これはあなたの場合には当てはまらないかもしれません。
于 2010-09-19T22:34:44.063 に答える
9
最初のものは、ユーザーテーブル全体を更新せずにタイプを表す文字列を変更できるため、より将来性があります。言い換えると、柔軟性のために導入された追加の不変の識別子である代理キーを使用します。
于 2010-09-19T22:32:35.733 に答える
4
（名前のような自然キーの代わりに）サロゲートキーを使用する正当な理由は、一意性の観点から自然キーが実際には適切な選択ではない場合です。私の生涯で、私は4つ以上の「クリススミス」を知っていました。人名は一意ではありません。
于 2010-09-19T22:32:54.390 に答える
4
私は代理キーを使用することを好みます。多くの場合、値を変更することを決定するまで、しばらくの間は問題のない自然キーを識別して使用します。その後、問題が始まります。
于 2010-09-19T22:38:07.970 に答える
3
おそらく常にID番号を使用する必要があります（そうすれば、タイプ名を変更した場合、ユーザーテーブルを更新する必要はありません）。INTでいっぱいのテーブルは1よりもはるかに小さいため、データサイズを抑えることもできます。 45文字のvarcharでいっぱいです。
于 2010-09-19T22:30:54.960 に答える
2
typeNameが自然キーの場合、値を取得するために結合を必要としないため、おそらくこれが推奨されるオプションです。
名前が変更される可能性がある場合にのみ、実際に代理キー（id）を使用する必要があります。
于 2010-09-19T22:29:56.800 に答える
1
私も代理キーをお願いします。
いくつかのコードを強打する必要がある場合、もう1つは簡単かもしれませんが、最終的には難しくなります。当時、私の技術上司は、主キーとして電子メールアドレスを使用することをお勧めしました。言うまでもなく、人々が自分の住所を変更したいと思ったとき、それは本当にひどいものでした。
于 2010-09-19T23:14:30.080 に答える
1
動作するときは常に自然キーを使用してください。通常、名前は機能しません。それらはあまりにも可変です。
独自のデータを発明する場合は、合成キーを発明することもできます。他の人またはそのソフトウェアによって提供されたデータのデータベースを構築している場合は、ソースデータを分析して、識別が必要なものをどのように識別しているかを確認します。
彼らがデータをうまく管理しているなら、彼らは重要なもののために働く自然キーを持っているでしょう。重要でないものについては、自分に合ってください。
于 2010-09-22T10:31:35.010 に答える
1
主キーと同じように値が関連していて意味のある一意に識別されたキーがない場合は、surrgoteキーが役立つと思います...さらに、surrgoteキーは実装が簡単で、保守のオーバーヘッドが少なくなります。
しかし一方で、surrgote keyは、テーブルを結合することによって余分なコストがかかる場合があります。「ユーザー」について考えてください...私は持っています
UserId varchar(20), ID int, Name varchar(200)
テーブル構造として。
今、私はレコードを挿入している人として多くのテーブルを追跡したいと考えています...Id主キーとして使用する場合、 [1,2,3,4,5..]etcは外部テーブルにあり、誰が参加するデータを挿入しているかを知る必要があるときはいつでも1,2,3,4,5,6意味がないので、それを使用したユーザーテーブル。しかし、UserId一意に識別される主キーとして使用すると、他の外部テーブル[john, annie, nadia, linda123]などに保存されます。これは、簡単に区別でき、意味のあるものになる場合があります。したがって、クエリを実行するたびにユーザーテーブルに参加する必要はありません。
ただし、varcharは余分なバイトを必要とする外部テーブルに保存されるため、物理的なスペースがいくらか余分に必要になります。もちろん、インデックス作成には、varcharよりもintのパフォーマンスが優れているという重大なパフォーマンスの問題があります。
于 2011-02-14T05:55:28.507 に答える
-1
代理キーは、自然の主キーの代わりになります。これは、テーブルの主キーに使用できる各行の一意の識別子または番号です。代理主キーの唯一の要件は、テーブルの各行で一意であることです。
自然な主キー（つまり、CustomerテーブルのCustomer Number）が変更される可能性があり、これにより更新がより困難になるため、これは便利です。
于 2016-08-16T01:02:07.017 に答える