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

Я также укажу, что письмо является плохим выбором для создания уникальной области, есть люди и даже малые предприятия, которые делят адрес электронной почты. И как номера телефонов, электронные письма могут быть повторно использованы. [email protected] может легко принадлежать Джону Смиту один год, а Джулия Смит - через два года.

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

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

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

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

• Медленнее при объединении.

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

• Можно изменить адрес электронной почты, который заставляет все записи использовать это как внешний ключ для обновления. Поскольку адрес электронной почты не меняет все часто, проблема с производительностью, вероятно, незначительна. Большая проблема заключается в том, что вы должны быть уверены в ее обеспечении. Если вам нужно написать код, это больше работы и вводит возможность ошибок. Если ваш механизм базы данных поддерживает "на каскаде обновления", это незначительная проблема.

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

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

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

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

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

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

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

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

Я не знаю, может ли это быть проблемой в вашей настройке, но в зависимости от вашей РСУБД значения столбцов могут быть чувствительны к регистру. В документах PostgreSQL говорится: "Если вы объявляете столбец как UNIQUE или PRIMARY KEY, неявно сгенерированный индекс учитывает регистр". Другими словами, если вы принимаете пользовательский ввод для поиска в таблице с адресом электронной почты в качестве первичного ключа, а пользователь предоставляет "[email protected]", вы не найдете "[email protected]".

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

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

systempuntoout спросил,

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

Что для каскадирование для.

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

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

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

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

вот так:

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

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

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

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

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

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

Как отметил @HLGEM, "[email protected] может легко принадлежать Джону Смиту один год, а Джулия Смит - через два года". в этом случае, если Джон Смит захочет получить ваше обслуживание, вам либо придется отказаться от использования своего адреса электронной почты, либо удалить все ваши записи, относящиеся к Джулии Смит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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