web-dev-qa-db-ja.com

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

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

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

postgresqlprimary-keyunique-constraint
11
aandis

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

候補キーは、テーブルの行を一意に識別するものです。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で一意であることを宣言します。

7
Lennart

はい、EmailAddress列に一意のインデックスがあっても問題ありません。唯一の問題は、サービスへのサインアップ後に誰かがメールアドレスをあきらめたが通知しなかった場合、そのメールアドレスの所有者がだれでもサインアップを試みることです。しかし、これはかなりまれなEdgeケースです。

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

6
mrdenny

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

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

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

2
vijayp