ユーザー名が一意であっても、varcharを主キーとして使用する代わりにid列を追加することにはいくつかの利点があります。
-
他の列が変更される可能性がある場合でも、変更する必要のない代理キーとして機能するために、主キーとして整数列を使用することを好む人もいます。自然主キーの変更を妨げるものは何もありませんが、カスケード外部キー制約を使用して、関連するテーブルの外部キーがそのような変更と同期して更新されるようにする必要があります。
-
varcharではなく32ビット整数である主キーを使用すると、スペースを節約できます。ユーザーテーブルを参照する他のすべてのテーブルでintまたはvarchar外部キー列を選択することは正当な理由になる可能性があります。
-
主キーインデックスへの挿入は、インデックスの中央にくさびで留めるよりも、インデックスの最後に新しい行を追加する方が少し効率的です。 MySQLテーブルのインデックスは通常B+Treeデータ構造であり、これらを調べてパフォーマンスを理解することができます。
-
一部のアプリケーションフレームワークは、データベース内のすべてのテーブルに
idと呼ばれる主キー列があるという規則を好みます。 、自然キーまたは複合キーを使用する代わりに。このような規則に従うと、特定のプログラミングタスクが簡単になります。
これらの問題はどれも取引を妨げるものではありません。また、自然キーを使用することには利点もあります：
-
IDで検索するよりもユーザー名で行を検索することが多い場合は、主キーとしてユーザー名を選択し、InnoDBのインデックス構成のストレージを利用する方がよい場合があります。 InnoDBでは主キールックアップの方が効率的であるため、可能であれば、主キー検索列を主キーにします（MySQLではInnoDBを使用する必要があります）。
-
お気づきのとおり、ユーザー名に一意の制約がある場合は、不要なID列を追加しておくのはストレージの無駄に思えます。
-
自然キーを使用するということは、外部キーに任意の整数IDではなく、人間が読める形式の値が含まれていることを意味します。これにより、クエリは「実際の」値のために親テーブルに結合し直す必要なしに外部キー値を使用できます。
重要なのは、100％のケースをカバーするルールがないということです。オプションを開いたままにし、単一のデータベースでも自然キー、複合キー、および代理キーを使用することをお勧めします。
代理キーの問題については、私の本の「IDが必要」の章で説明しています。 SQLアンチパターン：回避データベースプログラミングの落とし穴 。