文字ベースの ID フィールドを使用する場合と比較して、データベース テーブルで一意の数値 ID フィールドを使用する場合、パフォーマンスの向上やベスト プラクティスはありますか?
たとえば、2 つのテーブルがあるとします。
ID ... 17、名前... Rickey Henderson、チーム ID ... 28
チーム ID ... 28、チーム名...オークランド
チームIDが「28」または「31」ではなく、「OAK」または「SD」の場合、何千人ものプレーヤーがいるアスリートテーブルが読みやすくなります。teamidの値が一意であり、文字の形で一貫していることを当然のことと考えてみましょう。
文字を使用できることは知っていますが、何らかの理由でインデックス作成やフィルタリングなどに悪い考えはありますか?
これらのテーブルは例よりも複雑であるため、正規化の引数は無視してください。
無意味な数値である主キーは、長期的には頭痛の種を減らします。
あなたが言及したすべての理由から、テキストは問題ありません。
文字列が数文字しかない場合は、とにかく整数と同じくらい小さくなります。文字列を使用する最大の潜在的な欠点はサイズです。データベースのパフォーマンスは、必要なディスク アクセスの数に関係しています。たとえば、インデックスのサイズを 2 倍にすると、ディスク キャッシュに負荷がかかり、ディスク シークの回数が増える可能性があります。
私はあなたの例で転がるつもりです。Doug がテキストで問題ないと言っているのは正しいです。中規模 (~50 ギガ) のデータベースの場合でも、3 文字のコードを主キーにしても、データベースが強制終了されることはありません。開発が容易になり、他のテーブルの結合が減り、ユーザーが入力するフィールドになる場合...私はそれを選びます。ページに表示するのが単なる略語である場合や、アスリートのテーブルをきれいに見せるための場合は、使用しないでください。重要なのは、「これは、リストから選択するだけでなく、ユーザーが入力するコードですか?」という質問だと思います。
キーにテキスト列を使用した例を挙げましょう。私は医療請求を処理するためのソフトウェアを作っていました。請求がすべてデジタル化された後、人間は請求を見て、それがどのような種類の請求であるかを示すコードを選択する必要がありました。何百ものコードがありました...そして、これらの人たちはそれらをすべて暗記したり、彼らを助けるためにベビーシートを持っていました. 彼らは何年も同じコードを使用していました。3 文字のキーを使用すると、請求処理をスムーズに進めることができます。
キーとしてテキストを使用することは避けたいと思います。将来、チームのチーム ID を変更したい場合はどうなりますか? 主キーが回避できる正確なことである場合、そのキーの変更をデータ全体にカスケードする必要があります。また、経験的な証拠はありませんが、INT キーはテキスト キーよりも大幅に高速になると思います。
おそらく、数値の主キーを使用しながら、データを簡単に使用できるようにするデータのビューを作成できます。
標準的な答えは、インデックス作成が高速な数値を使用することです。ハッシュなどを計算する必要はありません。
意味のある値を主キーとして使用する場合、チーム名が変更された場合、データベース全体で更新する必要があります。
上記を満たしながら、データベースを直接読み取り可能にするには、
数値フィールドを主キーとして使用する
Athlete テーブルと Team テーブルを結合するビュー Athlete_And_Team をすぐに作成します。
その後、手動でデータを処理するときにビューを使用できます。
主キーには int または bigint を使用することをお勧めします。利点は次のとおりです。
team_code または「OAK」と「SD」の何かを保持する別の列をいつでも持つことができます。また
主キーまたはクラスター化インデックスについて話しているのですか? クラスター化インデックスは、その行を最も頻繁に一意に識別するために使用する列にする必要があります。また、テーブル内の行の論理的な順序も定義します。ほとんどの場合、クラスター化インデックスが主キーになりますが、異なる場合もあります。