3

ユーザー情報を格納するテーブルがあります。
ユーザテーブルでは、ユーザ名は一意です。ユーザー名をプライマリキーにする必要があると思いますか、またはint型の代理キーを使用する必要がありますか?
文字列キーを使用するとパフォーマンスが悪くなりますか?SQL Server - テーブルの主キーの選択

+3

これは、宗教的な戦争を開始する質問の種類です。 'username'が論理モデル内のキーである場合、それらは実装内のキー、すなわち少なくとも「ユニーク」、おそらくは「プライマリキー」となります。候補キーが複数ある場合は、すべてを実装する必要があり、どのキーを「プライマリ」にするかは任意です。あなたがサロゲートを追加することを選択した場合、最初に自然なキーが必要です(そして 'username'は妥当と思えますが)なぜ代理人が必要だと思うのか確かめてください:) – onedaywhen

答えて

9

サロゲート整数キーを使用します。

ユーザー名は頻繁に変更されることはありませんが、そうすることもできます。

パフォーマンスに関しては、問題があることがわかるまで、心配する必要はありません。

SQL Serverは、既定では主キー列にクラスタードインデックスを作成します。クラスタード・インデックスでワイド・キーを使用すると、クラスター化されていないすべてのインデックスにはそのワイド・キーも含まれます。

+1

おそらくユーザ名を変更するのは非常に良い点です。 –

+0

私の場合は、ユーザーにログイン名を変更させたくないと思っています。最初と最後の名前は変更できますが、登録された名前は変更できません。私はまだint pkと一緒に行くべきですか? –

+0

説明のために:その場合、私は追加の列で終わっていると思いませんか?それは性能に影響しないだろうか?他の重要な側面を残しながら、パフォーマンスに集中しすぎているかもしれません。あなたは私が紛失しているかもしれないものについて光を当てることができますか?ありがとう! –

6

通常、主キーとしてintを使用します。これは、他のテーブルの外部キーとして使用する場合、スペースを節約するだけでなく、コンベンションに一部起因します。実際には、ユーザ名フィールドをプライマリとして使用しても、それを使って複数のテーブルに何千ものレコードを保存しなければ、パフォーマンスが低下することはありません。あなたのテーブルが小さいままであると思うなら、それは好みまでです。

4

私はアイデンティティのサロゲート主キーとクラスタを使用します。クラスタード・インデックスはすべてのインデックスに含まれ、狭く、静的で、増加する必要があります。

プライマリキーでは、ユーザー名をプライマリキーにすることができますが、外部キーはそれを参照するため、静的(ユーザー名ではありません)にすることもできます。だから私はユーザー名にクラスタ化されていないユニークなインデックスを作成します。 ID PKは自動的にNCIに含まれます。

私はアクセスが主にユーザー名(パスワードハッシュ、おそらく名前など)である使用パターンに応じて、同じインデックス(含まれている列と同じ)に他の列を含めます。しかし、私は実行計画をチェックし、プロファイラやインデックスチューニングウィザードを使用して、予想されるワークロードを確認します。

関連する問題