各ユーザーに関する別の一意の情報が既にあることは明らかです。それはユーザー名です。では、なぜユーザーごとに別のユニークなものが必要なのでしょうか? 各ユーザーの ID も必要なのはなぜですか? id 列を省略するとどうなりますか?
5 に答える
ユーザー名が一意であっても、主キーとして varchar を使用する代わりに追加の id 列を使用する利点はほとんどありません。
他の列が変更される可能性がある場合でも、変更する必要のない代理キーとして機能するために、整数列を主キーとして使用することを好む人もいます。自然な主キーも変更可能であることを妨げるものは何もありませんが、カスケード外部キー制約を使用して、関連するテーブルの外部キーがそのような変更と同期して更新されるようにする必要があります。
主キーを varchar ではなく 32 ビット整数にすることで、スペースを節約できます。ユーザーテーブルを参照する他のすべてのテーブルで int または varchar 外部キー列を選択することは、正当な理由になる可能性があります。
主キー インデックスへの挿入は、新しい行をインデックスの最後に追加すると、インデックスの途中に挿入するよりも少し効率的になります。通常、MySQL テーブルのインデックスは B+Tree データ構造であり、これらを調べて、それらがどのように機能するかを理解できます。
id
アプリケーション フレームワークの中には、自然キーや複合キーを使用する代わりに、データベース内のすべてのテーブルに と呼ばれる主キー列があるという規則を好むものがあります。このような規則に従うことで、特定のプログラミング タスクを簡単にすることができます。
これらの問題はいずれも契約を破るものではありません。また、自然キーを使用する利点もあります。
ID で検索するよりもユーザー名で行を検索する頻度が高い場合は、ユーザー名を主キーとして選択し、InnoDB のインデックス編成ストレージを利用することをお勧めします。主キー検索は InnoDB の方が効率的であるため (MySQL では InnoDB を使用する必要があります)、可能であれば、主検索列を主キーにします。
お気づきのように、ユーザー名に既に一意の制約がある場合、必要のない余分な id 列を保持するのはストレージの無駄のようです。
自然キーを使用するということは、外部キーに、任意の整数 ID ではなく、人間が判読できる値が含まれることを意味します。これにより、「実際の」値のために親テーブルに結合し直すことなく、クエリで外部キー値を使用できます。
ポイントは、100% のケースをカバーするルールがないということです。オプションを開いたままにし、単一のデータベースでも自然キー、複合キー、および代理キーを使用することをお勧めします。
私の著書SQL Antipatterns: Avoiding the Pitfalls of Database Programming の「ID Required」の章で、代理キーの問題をいくつか取り上げています。
この識別子はサロゲート キーと呼ばれます。リンクしたページには、長所と短所の両方がリストされています。
実際には、スーパーキー データでさえ時間の経過とともに変化する可能性があるため (つまり、ユーザーの電子メール アドレスが変化する可能性があるため、対応する関係も変化しなければならない)、それらが有利であることがわかりましたが、代理キーはそれが識別するデータに対して決して変更する必要はありません。関係にとって値は無意味です。
JOIN
varchar よりもキーの長さが短い整数を使用できるため、観点からも優れています。
実際には、それらを使用することを好むと言えます。複数の列の主キーまたはデータを表すスーパーキーを複数のテーブルで使用することで、開発中に要件が変更されたため、後で非一意になる必要があることに何度も悩まされてきましたが、これは対処したくない状況です。
im mysql があります。
1:Index fields 2:Unique fields and 3:PK fields.
index means pointable
unique means in a table must be one in all rows.
PK = index + unique
テーブルには、ユーザー名、パスポート コード、電子メールなどの一意のフィールドが多数ある場合があります。
ただし、ID のようなフィールドが必要です。これは一意かつインデックス (=PK) の両方です。最初は常に 1 つのことであり、変更されることはありません。2 番目は一意であり、3 番目は単純です (数値であることが多いため)。