Дизайн базы данных: электронная почта как идентификатор таблицы

Question

Я работаю над веб-приложением Java. Для аутентификации я требую, чтобы пользователь вводил свой адрес электронной почты и пароль. Теперь я использую JPA 2, что, возможно, не так важно.
Если электронное письмо было ключом таблицы Users, это упростило бы мою жизнь. Я мог бы сделать простой:

User selected = em.find(User.class, userEmail); 

См ?, Кроме того, каждый адрес электронной почты уникален, он не имеет места и т.д. Теперь, никто не делает это, я предполагаю, что есть причина. У меня тоже есть сомнения, я имею в виду, это варчар и т. Д. Но вы думаете, что это хорошая идея? Если нет, то почему ?. Это должно быть веской причиной, так что компромисс не стоит. Цифровые клавиши всегда лучше всего, но здесь я снова и снова сталкиваюсь с электронной почтой пользователя и постоянно просматриваю их по электронной почте, никогда не используя идентификатор, за исключением столбцов соединения и т. Д.

Answer 1

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

Answer 2

Помимо

• отходов космоса.
• Проблемы с производительностью в соединениях.
• Отходы пространства в индексах.

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

Answer 3

В таблице могут быть несколько ключей. Сделайте электронный ключ для кандидата. Мне нравится думать о том, как ПК работает на президента США. У вас есть несколько кандидатов, но только 1 может быть президентом.

Что говорят другие, хорошо. Если значение изменяется, вы не хотите обновлять 30 других таблиц. Это означает суррогатный ключ (ключ без смысла, кроме определения строки). Поскольку суррогаты не имеют никакого значения, вам не нужно беспокоиться об изменении их стоимости. Обычно они являются целыми числами с автоматическим приращением.

Назад к точке оргинала. Ваш код:

User selected = em.find(User.class, userEmail); 

Этот код должен быть абсолютно верным, независимо от того, является ли он основным или потенциальным ключом. Если ваша структура НЕОБХОДИМА поиск по первичным ключам, тогда вам лучше начать кричать, потому что в реальном мире вы ищете гораздо больше, чем просто ПК.