私はテーブルを持っていますUsers
。
そして、私はプライマリとして自動増加ロングIDを持っています。ここで、ユーザー名も一意である必要があります。ベストプラクティスは何でしょうか?
ユーザー名のみを保持し、数値IDのみを削除する必要がありますか?どういうわけか両方をユニークにする必要がありますか?おすすめは何ですか?
たぶん、休止状態を使用することにも言及する必要があります。
私はテーブルを持っていますUsers
。
そして、私はプライマリとして自動増加ロングIDを持っています。ここで、ユーザー名も一意である必要があります。ベストプラクティスは何でしょうか?
ユーザー名のみを保持し、数値IDのみを削除する必要がありますか?どういうわけか両方をユニークにする必要がありますか?おすすめは何ですか?
たぶん、休止状態を使用することにも言及する必要があります。
通常、ユーザー名に「一意の制約」を追加します。自動インクリメントIDを持つことは厳密には必要ありませんが、「自然キー」を使用しないのが一般的な方法です。この関連する質問を参照してください: ネイティブ主キーまたは自動生成された主キー?。
ユーザー名を一意に保つには、次のことを行う必要があります。
ALTER TABLE Users
ADD CONSTRAINT constraint_name UNIQUE (username);
主キーを変更する必要はありません。id
主キーがあると便利です。UPDATE
また、リンクされたテーブルを使用せずに、ユーザー名を変更できます。
UPD:2つのPK(1つは実数、もう1つは「半」PK)を維持したくない場合は、テーブルがUPDATE/INSERT/DELETE
1秒あたりのトン数を取得する場合のみです。この場合、2つのインデックスと1つのインデックスのオーバーヘッドが顕著になる可能性があります。
アプリケーションの使用方法によって異なります。ユーザー名が変更される可能性がある場合は、主キーとしてIDを使用することをお勧めします。コードにチェックを入れて、作成時にユーザー名が一意であることを確認できます。
データベースからデータにアクセスするときは、ID(主キー)を使用するのが一般的です。これは、他の何かを使用する場合にデバッグが困難な意図しない動作を引き起こす可能性があるためです。
ユーザー名を変更することはできますか?そうでない場合は、主キーとして使用できます。これは自然キーであるため、私の意見では、現在使用しているような代理キーよりも優れています。
ユーザー名が変更される可能性がある場合は、主キーとしての使用には適していません。
将来発生する可能性のあるすべてのシナリオを知ることはできないので、ユーザー名を変更する必要がある可能性を排除することはできないと思います。したがって、代理キーは将来性のあるオプションです。
主キーではない場合でも、ユーザー名に一意の制約を設定することはまったく問題ありません。また、null以外の制約も必要になる可能性があります。