Полезно ли использовать адрес электронной почты в качестве первичного ключа во многих таблицах системы веб-сайта?

Question

Например, такой веб-сайт, как stackoverflow.com, является ли хорошей практикой использование адреса электронной почты для идентификации пользователей во многих таблицах?

Это плохо, если первичный ключ очень длинный, скажем,

VARCHAR (50)

или даже

VARCHAR (100)

Answer 1

Не совсем. Для любого значительного набора данных вы в конечном итоге будете тратить много места, а при запросах вы будете терять производительность. Кроме того, если кто-то меняет свою электронную почту (которую вы можете или не можете разрешить), вы должны изменить ее везде.

Суррогатный ключ для уникальной идентификации пользователя был бы намного лучшим выбором.

Answer 2

Нет. Во-первых, что если один и тот же пользователь задает два вопроса? Если электронная почта была первичным ключом, то теперь у нас нарушение PK.

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

В-третьих, вы должны просто использовать что-то вроде идентификатора с автоинкрементом. Строка (например, адрес электронной почты) будет ужасно неэффективной.

Если вам нужно связать вопрос с конкретным участником, добавьте внешний ключ memberID в таблицу member. Таблица ответов должна иметь свой собственный автоматически увеличивающийся идентификатор с внешним ключом questionID в таблице question и внешним ключом memberID в таблице member, представляющим члена, предоставившего ответ. Etc.

Кстати, вы можете узнать о нормализации базы данных , по крайней мере, до третьей нормальной форме (3NF). Это не пизда, это просто здравый смысл.

Answer 3

В дополнение ко всем причинам, почему вам не нужна строка в качестве первичного ключа в таблицах , есть также несколько очень специфических причин, по которым электронная почта, в частности, не должна использоваться в качестве первичного ключа:

• Первичные ключи должны быть уникальными. Однако нормализовать адрес электронной почты сложно. У вас может быть много проблем с обеспечением уникальности. (Адреса электронной почты чувствительны к регистру? Вы игнорируете. Или + внутри электронных писем? Как вы сравниваете неанглийские электронные письма?)

• Электронная почта является личной информацией. Использование ее в любых целях может быть проблемой безопасности и конфиденциальности . Особенно, если некоторые из ваших пользователей младше 13 лет.

• Электронная почта не является неизменной, так как ее не следует использовать в качестве удостоверения личности ( Должен ли я использовать номер или идентификатор электронной почты для идентификации пользователя на сайте? ) , Таким образом, если пользователь меняет свою электронную почту, вы должны либо: а) обновить первичные ключи всех ваших таблиц, либо б) сохранить старую электронную почту в качестве ключа, что делает использование электронной почты в качестве ключа бесполезным для начала.

Answer 4

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

Если ваши столбцы проиндексированы правильно, большинство современных баз данных (Oracle, Postgres, SQLServer) не будут чрезмерно наказывать вас за присоединение к адресу электронной почты. Если вас беспокоит объединение, создайте денормализованный материализованный вид и заплатите цену при вставке / обновлении.

Answer 5

Нет, это плохая идея. Письма меняются, и сравнения строк относительно дороги.

Answer 6

Этот пост от Jay Pipes о сравнении различий между int и char для первичного ключа может помочь понять, почему следует использовать целые числа.