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

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

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

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

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

Сравнение строк медленнее, чем сравнение int. Однако это не имеет значения, если вы просто извлекаете пользователя из базы данных, используя адрес электронной почты. Имеет значение, если у вас есть сложные запросы с несколькими объединениями.

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

Я также укажу, что электронная почта - плохой выбор для создания уникального поля, есть люди и даже малые предприятия, которые имеют адрес электронной почты. Как и номера телефонов, электронные письма могут быть использованы повторно.Jsmith@somecompany.com может легко принадлежать Джону Смиту один год и Джулии Смит два года спустя.

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

первичный ключ должен быть уникальным и постоянным

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

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

1. Медленнее, когда делает соединения.

2. Любая другая запись с опубликованным внешним ключом теперь имеет большее значение и занимает больше места на диске. (Учитывая стоимость дискового пространства сегодня, это, вероятно, тривиальная проблема, за исключением того, что запись теперь занимает больше времени для чтения. См. № 1.)

3. Адрес электронной почты может измениться, что приведет к обновлению всех записей, использующих его в качестве внешнего ключа. Поскольку адреса электронной почты меняются не так часто, проблема с производительностью, вероятно, незначительна. Большая проблема в том, что вы должны убедиться, что обеспечили это. Если вам нужно написать код, это больше работы и вводит возможность ошибок. Если ваша база данных поддерживает «каскад обновления», это незначительная проблема.

Преимущества использования адреса электронной почты в качестве первичного ключа:

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

2. Когда вы делаете специальные запросы, человеку легко увидеть, на какую основную запись ссылаются. Это может помочь при попытке отследить проблемы с данными.

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

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

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

... и я даже не начал говорить о соображениях производительности.

Я не знаю, может ли это быть проблемой в вашей установке, но в зависимости от вашей RDBMS значения столбцов могут быть чувствительными к регистру . Документы PostgreSQL говорят: «Если вы объявляете столбец как UNIQUE или PRIMARY KEY, неявно генерируемый индекс чувствителен к регистру». Другими словами, если вы принимаете пользовательский ввод для поиска в таблице с электронной почтой в качестве первичного ключа, и пользователь предоставляет «John@Doe.com», вы не найдете «john@doe.com».

Кажется, никто не упомянул о возможной проблеме, заключающейся в том, что адреса электронной почты могут считаться частными. Если адрес электронной почты является первичным ключом, URL страницы профиля, скорее всего, будет выглядеть примерно так ..../Users/my@email.com. Что если вы не хотите показывать адрес электронной почты пользователя? Вам нужно найти какой-то другой способ идентификации пользователя, возможно, с помощью уникального целочисленного значения, чтобы сделать URL-адреса похожими ..../Users/1. Тогда вы получите уникальное целочисленное значение.

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

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

systemmpuntoout спросил,

Что если кто-то захочет изменить свой адрес электронной почты? Собираетесь ли вы также изменить все внешние ключи?

Вот что каскадно .

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

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

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

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

как это:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первичный ключ должен быть выбран статическим атрибутом. Поскольку адреса электронной почты не являются статичными и могут совместно использоваться несколькими кандидатами, не рекомендуется использовать их в качестве первичного ключа. Кроме того, адреса электронной почты - это строки, обычно определенной длины, которые могут быть больше уникального идентификатора, который мы хотели бы использовать [len (email_address)> len (unique_id)], поэтому для этого потребуется больше места, и даже в худшем случае они хранятся несколько раз как внешний ключ , И, следовательно, это приведет к снижению производительности.

Это зависит от таблицы. Если строки в вашей таблице представляют адреса электронной почты, то лучшим идентификатором будет электронная почта. Если нет, то электронная почта не является хорошим идентификатором.

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

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

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