私のすべてのテーブルには、Id何らかのタイプのフィールドがあります（UserId, PostId, FooIdなど）。私は通常、これをPrimary Keyにします。
私が持っているテーブルは と呼ばれていCountriesます。それは持っています
CountryId SMALLINT
Name VARCHAR(100) -- Yes, english country names only, in this column.
AndSomeOtherFields.
今、私はNameが一意でなければならないことを知っています。すべての国名は一意です。PrimaryKey==CountryId ASC と _ Name ASC_
それが良い場合、誰かが単にIdPK であるよりも優れている理由を説明できますか? データの整合性を保証するだけですか（たとえば、テーブルに2つの国名が存在しません）。それが悪いなら..なぜですか？
よろしくお願いします。
主キーを と の両方CountryId に Nameすることは、名前が一意であることを保証しません。CountryId各-Name ペアが一意であることを保証するだけであり、明らかCountryIdにすでに一意であり、「ID」です。したがって、ペアが一意であるため、たとえば と を引き続き使用できます1-US。19-US
両方を主キーにする唯一の理由は、Where 句で CountryId と Name の両方が使用されているクエリを頻繁に実行する場合です。主キーはデフォルトで、テーブルを物理的にソートするクラスター化インデックスを作成するため、これらの述語に対する行の検索が非常に高速になります。
提起するもう1つの重要な点は、あなたの特定の例では、a）非常に短く、b）あまり変わらない国のリストを保存していることです。このテーブルに対するルックアップは、何をしても非常に高速になります。SQL Server が毎回フル テーブル スキャンを実行しなければならない場合でも、おそらく気付かないでしょう。ページの断片化について心配する必要はありません。ID 列をスキップしNameて、主キーとして使用できます。
または、ID を保持しながら国名のみの一意性を強制する場合は、[名前] 列に一意の制約を設定できます。
主キー、クラスター化インデックス、およびインデックス全般の問題を 1 つの回答で詳しく説明することは困難です。開始するためのいくつかの優れたリソースを次に示します。
名前を PK にすることが常に最善の解決策であるとは限りません。テーブルの PK としては CountryId で十分だと思いますが、 Name が selects,joins などでクエリを行うために多く使用するフィールドである場合は、これにインデックスを付ける必要があります。この方法でフィールドをフィールドすると、このフィールドでフィルタリングするクエリにより、速度が大幅に向上します
幸運を ：）
列に一意のインデックスを作成しますName。
私が考えることができる唯一のことは、非常に明白です: あなたのインデックスは少し大きくなります. そうは言っても、テーブルには国のみが保存されるため、それほど大したことではありません。しかし、なぜそのようなインデックスが必要なのですか? CountryIdで並べ替えた場合、2 番目のフィールドとしてNameで並べ替えても意味がありません。いつも同じ注文になります。
非常に悪い考えの 1 つは、外部キーが大きな主キーを指すようにすることです。そのため、その主キーを使用する場合、Countriesを指す外部キーは引き続きCountryId列のみを使用するようにしてください。
国名は、国の独自性を変更することなく変更されることが知られています。これは、名前が PK の一部であってはならないことを示唆しています。
一意性を強制する必要がある場合は、制約を使用してください。