Адрес электронной почты уникальный или первичный ключ?

Я новичок в базах данных. Я прочитал вокруг и обнаружил, что, вероятно, не очень хорошая идея использовать адрес электронной почты в качестве первичного ключа, потому что сравнение строк медленнее, что влияет на производительность в сложных объединениях, и если электронное письмо изменится, мне придется изменить все внешние ключи, что требует много усилий.

Но если моя таблица пользователей требует, чтобы у каждого пользователя был адрес электронной почты, и каждый из этих адресов электронной почты должен быть уникальным, будет ли достаточно добавить уникальный индекс в столбец электронной почты? Потому что уникальные поля afaik допускают нулевые значения, тогда как я требую, чтобы у каждого пользователя был адрес электронной почты, а недопустимые нулевые значения. Есть что-то, чего я здесь не хватает? Или я предполагаю сделать столбец электронной почты уникальным и убедиться, что во время проверки данных на сервере, что пользователь вводит адрес электронной почты, чтобы он был у каждого пользователя?

Давайте сначала проведем различие между ключами и индексами, ключ является частью логической модели и часто реализуется с уникальным индексом. Однако вы можете создать уникальный индекс без создания ключа, но на него не может ссылаться внешний ключ.

Ключ-кандидат - это то, что однозначно идентифицирует строку в таблице, в SQL один из ключей-кандидатов обычно используется в качестве первичного ключа (я так и не понял, почему один из 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 - это еще один вид ограничений. В вашем случае вы можете применить это к электронной почте, не объявляя ее уникальной.

Следующий аспект вашего сообщения касается стабильности ключа, ключ должен быть стабильным (но это не значит, что он никогда не может измениться, он не должен быть неизменным). Некоторые СУБД реализуют ПО ОБНОВЛЕНИЮ КАСКАД, который может помочь в такой операции, но если ключ распределен по вашей модели, обновление будет затруднительно.

В вашем случае я, вероятно, выбрал бы другой кандидатный ключ в качестве первичного ключа и объявил бы, что электронная почта НЕ НЕДЕЙСТВИТЕЛЬНА и УНИКАЛЬНА.

Да, иметь уникальный индекс в столбце EmailAddress должно быть в порядке. Единственная проблема заключается в том, что если кто-то отказался от адреса электронной почты после регистрации на вашем сервисе, но не сказал вам об этом, то кто бы ни пытался зарегистрироваться владельцем электронной почты. Но это довольно редкий крайний случай.

Что касается, если уникальный индекс допускает нулевые значения, которые будут зависеть от вашей платформы базы данных. Oracle делает, SQL Server допускает одно значение NULL. Вы можете решить эту проблему, запретив столбцу значения NULL, а затем создав для него уникальный индекс.

Иметь уникальный индекс на EmailAddress - это хорошо.

Так как вы уже заявили, что в вашем приложении есть проверка на наличие адреса электронной почты в качестве обязательного поля, я бы сказал, так как другая проверка будет из базы данных, это не прием пользователя без адреса электронной почты, а также предотвращение дублирования ввода, и эти проверки будет навязан с помощью этого уникального индекса.

Как указано в другом ответе для SQL Server, необходимо создать столбец, не допускающий нулевое значение, прежде чем создавать уникальные индексы.