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

Question

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

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

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

Answer 1

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

Answer 2

Помимо

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

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

Answer 3

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

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

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

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

Этот код должен быть совершенно действительным, независимо от того, является ли электронная почта первичным ключом или ключом-кандидатом. Если ваш фреймворк ТРЕБУЕТ поиска по первичным ключам, вам лучше запустить screaming, потому что в реальном мире вы ищете гораздо больше, чем просто PK.