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

Question

Является ли адрес электронной почты плохим кандидатом на основной адрес по сравнению с автоматически увеличивающимися числами?

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

Является ли действительной причиной не использовать электронную почту в качестве первичного ключа?

Мы используем PostgreSQL.

Answer 1

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

Answer 2

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

Answer 3

Я не слишком знаком с postgres.Первичные ключи - это большая тема.Я видел несколько отличных вопросов и ответов на этом сайте (stackoverflow.com).

Я думаю, что у вас может быть лучшая производительность, если вы используете числовой первичный ключ и используете УНИКАЛЬНЫЙ ИНДЕКС в столбце электронной почты.Электронные письма, как правило, различаются по длине и могут не подходить для индекса первичного ключа.

некоторые читают здесь и здесь.

Answer 4

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

Как отметил @HLGEM, «Jsmith@somecompany.com может легко принадлежать Джону Смиту один год и Джулии Смит два года спустя». в этом случае, если Джон Смит захочет воспользоваться вашим сервисом, вы должны либо отказаться от использования его адреса электронной почты, либо удалить все свои записи, относящиеся к Джулии Смит.

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

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

Answer 5

Используйте GUID в качестве первичного ключа ... таким образом, вы можете сгенерировать его из своей программы, когда выполняете INSERT, и вам не нужно получать ответ от сервера, чтобы узнать, что такое первичный ключ.Это также будет уникально для таблиц и баз данных, и вам не нужно беспокоиться о том, что произойдет, если вы однажды урежете таблицу, и автоинкремент будет сброшен до 1.

Answer 6

Ваш коллега прав: используйте автоинкрементное целое число для вашего первичного ключа.

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

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

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

Answer 7

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

Если вам необходимо сохранить саму запись в базе данных по ссылочной целостности или историческим причинам, таким как аудит, использование суррогатного ключа позволит вам просто ОБНОВИТЬ все поля персональных данных. Это, очевидно, не так просто, если их личные данные являются первичным ключом

Answer 8

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

Answer 9

Если в качестве первичного ключа вы используете не int-значение, вставка и извлечение данных будут очень медленными.

Answer 10

Вы можете повысить производительность с помощью целочисленного первичного ключа.