メールアドレスは一意ですか、それとも主キーですか？

私はデータベースの初心者です。文字列の比較が遅く、複雑な結合のパフォーマンスに影響するため、メールアドレスを主キーとして使用することはおそらく良いアイデアではないことがわかりました。メールを変更すると、すべての外部キーを変更する必要があり、多くのことを必要とします。努力の。

しかし、私のユーザーテーブルですべてのユーザーがメールアドレスを持っている必要があり、それらのメールアドレスはそれぞれ一意である必要がある場合、メール列に一意のインデックスを追加するだけで十分ですか？Afaikの一意のフィールドではnull値が許可されているため、私はすべてのユーザーがnull値を許可せずに電子メールアドレスを持っている必要があります。ここで見逃しているものはありますか？または、電子メール列を一意にし、サーバーでのデータ検証中に、ユーザーが電子メールアドレスを入力してすべてのユーザーが1つ持つことを確認するとしますか？

最初にキーとインデックスを区別しましょう。キーは論理モデルの一部であり、多くの場合、一意のインデックスで実装されます。ただし、キーを作成せずに一意のインデックスを作成することはできますが、外部キーから参照することはできません。

候補キーは、テーブル内の行を一意に識別するものです。SQLでは、通常、候補キーの1つが主キーとして使用されます（ckの1つが他よりも「優れている」と考えられている理由は本当にわかりませんが、それはもう1つです。ストーリー）、残りのckは一意の制約になります。

一意制約は、主キーと同じように使用できます。検討してください：

create table A ( x ... not null
               , y ... not null
               , z ... not null
               ,     unique (x)
               ,     primary key (y,z) );

create table B ( x ...
               ,   ...
               ,     foreign key (x) references A (x) );

create table C ( y ...
               , z ...
               ,   ...
               ,     foreign key (y, z) references A (y, z) );  

Bは一意制約を参照し、Cは主キー制約を参照します。

NOT NULLは、さらに別の種類の制約です。あなたの場合、あなたはそれをユニークに宣言せずにこれをメールに強制することができます。

投稿の次の側面は、キーの安定性に関係します。キーは安定している必要があります（ただし、変更できないことを意味するわけではなく、不変である必要はありません）。一部のDBMSは、このような操作に役立つON UPDATE CASCADEを実装していますが、モデルの周囲にキーが分散されている場合は、更新に手間がかかります。

あなたの場合、おそらく私は主キーとして別の候補キーを選択し、電子メールがNOT NULLで一意であることを宣言します。

はい、EmailAddress列に一意のインデックスがあっても問題ありません。唯一の問題は、誰かがあなたのサービスにサインアップした後にメールアドレスをあきらめたが、あなたに言わなかった場合、そのメールアドレスの所有者がサインアップしようとする人です。しかし、それはかなりまれなエッジケースです。

一意インデックスがデータベースプラットフォームに依存するnull値を許可するかどうかについて。Oracleでは、SQL Serverは単一のNULL値を許可しています。これを解決するには、列にNULL値を許可せず、その列に一意のインデックスを作成します。

EmailAddressに一意のインデックスがあれば問題ありません。

必須フィールドとしてメールアドレスを使用するためのアプリケーションの検証があることをすでに述べたように、他の検証はデータベースからのものであるため、メールアドレスを持たないユーザーを受け入れず、エントリの重複とこれらの検証を防止しますこの一意のインデックスが課されます。

SQL Serverの他の回答で述べたように、一意のインデックスを作成する前に、列にnull値を許可しないようにする必要があります。