Унікальний або первинний ключ електронної адреси?

Я новачок у базах даних. Я прочитав навколо, і дізнався, що, мабуть, не чудова ідея використовувати адресу електронної пошти в якості основного ключа, оскільки порівняння рядків повільніше, що впливає на ефективність у складних з'єднаннях, а якщо зміна електронної пошти, мені доведеться змінити всі зовнішні ключі, що вимагає багато зусиль.

Але якщо моя таблиця користувачів вимагає від кожного користувача електронної адреси, і кожна з цих адрес електронної пошти має бути унікальною, чи буде достатньо додати унікальний індекс у стовпці електронної пошти? Оскільки унікальні поля afaik дозволяють нульові значення, тоді як я вимагаю від кожного користувача електронної адреси, не допускаючи нульових значень. Щось тут мені не вистачає? Або я вважаю, щоб зробити стовпець електронної пошти унікальним і переконатися, що під час перевірки даних на сервері користувач вводить електронну адресу, щоб кожен користувач мав його?

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

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