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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

1. Медленнее при выполнении объединений.

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

systemmpuntoout спросил,

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

Вот для чего каскад .

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

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

Answer 9

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

Answer 10

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

как это:

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