int 主キーの代わりに nvarchar(50) を主キーとして使用するようにいくつかのテーブルを変更することを検討しています。キーに int ID を使用することは実際には無関係なデータです。それは私が興味を持っている文字列です。どのような種類のパフォーマンス ヒットが発生するか、またはこれをどこで調査しますか? カットアンドトライ以外は。
5 に答える
データベース設計の主要な「聖戦」の 1 つに遭遇しました。あなたが言及している議論は、RDBMSが存在する限り(私が知る限り)激怒している「サロゲートvs.自然キー」の議論です。
議論は本質的に、レコードを一意に記述する実際のデータ (自然キー) を使用するのではなく、代表的なキー (IDENTITY 列などのサロゲート) を使用する必要があるかどうかに要約されます。
「正解」はないと断言します。パフォーマンス測定値はプラットフォームのアーティファクトであり、実験によって評価する必要がありますが、パフォーマンスは主要な関心事ではない可能性があります.
代理キーの主要な議論であると私が考えるのは、主キーの不変性です。自然キーを使用することを選択した場合は、そのキーが確立された後にそのキーを変更するオプションを放棄します。また、将来のある時点で一意でなくなる可能性も放棄します。これらの理由から、私は通常 (常にではありませんが)、ほとんどのテーブルに代理キーを使用しています。
ただし、前述したように、索引付け戦略と標準形式の遵守に関する議論で満たされた非常に長期にわたる議論があり、興味がある場合は読む必要があります。
「代理キーと自然キー」をグーグルで検索します。開始するためのいくつかのリンクを次に示します。
お役に立てれば。
代理キー (int 主キー) を主キー/クラスター化インデックス キーとして使用することを検討してください。nvarchar(50) を主キー/クラスター化インデックス キーとして使用する際の問題は、テーブルがそのキーによって順序付けられることです。これは、テーブルが高度に断片化される可能性が高いことを意味し、他のインデックスにはこの重い参照の負担がかかることを意味します。主キー。
別の問題は、キーのサイズが大きくなるにつれて、より高価な操作であるこのタイプの値によって、おそらく他のテーブルで JOIN する必要があることです。
nvarchar(50) 主キーが意味を持つ状況はほとんどないと思います。
通常、小さな自然な不変キーがない限り、主キーはサロゲートにする必要があります。おそらく、たとえば、SSN は自然の不変キーと見なすことができます。
パフォーマンスのために、私は通常次のように尋ねます。
何列?1,000 または 1,000,000 または 10,000,000 ??
どのサーバーに座っていますか?(メモリ、ディスク容量)
私はそれをプロファイリングしてから見ます。通常、ボトルネックはデータベースではなく、コードの記述が不十分である、デプロイが不適切であるなどです。
自然キーソリューションのリーダーによって提案されたすべての議論を確実に焼き尽くすために(サロゲートと自然キー戦争を参照)、簡潔にするために、サロゲートキーは常に機能しますが、自然キーはリードする傾向が緩いです問題や欲求不満に、通常は予期しないときに。
それらがすべての状況に最適なソリューションであるとは言いませんが、テーブルを作成するときに最適な自然キーの適切なパラメーターを考える時間を失うことを避けるために、サロゲートを選択するだけで完了です。また、テーブルに適切な自然キーがあると思われる場合は、(一意の?)インデックスを持つフィールドとして追加するだけです。
また、開発者が簡単に使用できるように、常に最初のフィールドを主キーとして使用し、2番目のフィールドを想定/疑似自然キーにします。テーブルは次のようになります。
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, nvarchar(your favorite length), indexed
.....
ここで、id_は主キーのプレフィックスであり、code_は「自然な」インデックス付きフィールドに使用されます
なぜUNICODE?たとえば、英語の単語を漢字に翻訳した場合、それらは重複していると見なされますか?
なぜ可変なのですか?固定幅は、キーの優れた物理的特性です。
なぜ50文字?これはユーザーにとって多くのキーイングです(「キーのint IDは実際には無関係なデータである」ことに同意し、そのようないわゆる「代理キー」はエンドユーザーに公開されるべきではないと思います、ところで)。
また、私にとってNVARCHAR(50)
はちょっとした「匂い」があります。Microsoftのデフォルトであり、MSAccessからのストレートポートでしょうか。これは、もちろん、キーについて十分な考慮と考慮を払っていないという意味ではありません。もちろん、レビューする必要があるものの1つにすぎません。
ちょっと待ってください:あなたは特に主キーを意味しましたよね?1つの(テーブルごとの)クラスター化インデックスを明示的に使用すると仮定すると、AFAIK PRIMARY KEYの指定は、SQLServerの土地に物理的な影響を及ぼしません。もちろん、すべての候補キーはNOTNULLUNIQUE制約でカバーされている必要があります。PRIMARYキーにプロモートすることを選択したものは任意です。