Використовувати електронну адресу як основний ключ?

Чи є адреса електронної пошти поганим кандидатом для первинних у порівнянні з автоматичним збільшенням номерів?

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

Чи поважна причина не використовувати електронну пошту в якості основного ключа?

Ми використовуємо PostgreSQL.

Порівняння рядків повільніше, ніж порівняння int. Однак це не має значення, якщо ви просто отримаєте користувача з бази даних за допомогою адреси електронної пошти. Не має значення, якщо у вас є складні запити з кількома приєднаннями.

Якщо ви зберігаєте інформацію про користувачів у кількох таблицях, іноземними ключами до таблиці користувачів буде адреса електронної пошти. Це означає, що ви зберігаєте електронну адресу кілька разів.

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

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

первинний ключ повинен бути унікальним і постійним

Адреси електронної пошти змінюються, як пори року. Корисний як вторинний ключ для пошуку, але поганий вибір для первинного ключа.

Недоліки використання електронної адреси в якості основного ключа:

1. Повільніше, коли ви приєднуєтесь.

2. Будь-яка інша запис із розміщеним іноземним ключем тепер має більше значення, займаючи більше місця на диску. (Враховуючи вартість дискового простору сьогодні, це, мабуть, тривіальна проблема, за винятком того, наскільки зараз запису потрібно більше часу для читання. Див. №1.)

3. Електронна адреса може змінитися, що змушує оновлювати всі записи, що використовують це як зовнішній ключ. Оскільки адреса електронної пошти не змінюється все так часто, проблема ефективності, ймовірно, незначна. Більша проблема полягає в тому, що ви повинні переконатися в цьому. Якщо вам доведеться написати код, це більше роботи і вводить можливість помилок. Якщо двигун бази даних підтримує "на каскаді оновлень", це незначна проблема.

Переваги використання електронної адреси в якості основного ключа:

1. Можливо, ви зможете повністю усунути деякі приєднання. Якщо все, що вам потрібно з "основного запису", - це адреса електронної пошти, то з абстрактним цілим ключем вам доведеться зробити об'єднання, щоб отримати його. Якщо ключем є адреса електронної пошти, то ви її вже маєте, і приєднання є непотрібним. Чи допоможе вам це чимось, залежить від того, як часто виникає така ситуація.

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

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

На мою скромну думку, це не так, як у суєтах. Я, як правило, вважаю за краще використовувати природні ключі, коли є доступний практичний, тому що з ними просто простіше працювати, а недоліки, як правило, не мають великого значення в більшості випадків.

Це досить погано. Припустимо, якийсь постачальник електронної пошти не працює. Потім користувачі захочуть змінити свою електронну пошту. Якщо ви використовували електронну пошту в якості основного ключа, всі закордонні ключі для користувачів дублюватимуть цю електронну пошту, зробивши її досить проклято важко змінити ...

... і я навіть не говорив про міркування щодо продуктивності.

Я не знаю, чи це може бути проблемою у вашій наладці, але залежно від RDBMS значення стовпців можуть залежати від регістру . Документи PostgreSQL кажуть: „Якщо ви оголошуєте стовпець як УНІКАЛЬНИЙ або ПЕРВИЧНИЙ КЛЮЧ, то імпліцитно генерований індекс відрізняється від регістру“. Іншими словами, якщо ви приймаєте введення користувача для пошуку в таблиці з електронною поштою в якості основного ключа, а користувач надає "John@Doe.com", ви не знайдете "john@doe.com".

Здається, ніхто не згадував про можливу проблему, що адреси електронної пошти можна вважати приватними. Якщо адреса електронної пошти є основним ключем, URL-адреса сторінки профілю, швидше за все, буде виглядати приблизно так ..../Users/my@email.com. Що робити, якщо ви не хочете виставляти електронну адресу користувача? Вам потрібно буде знайти інший спосіб ідентифікації користувача, можливо, за допомогою унікального цілого значення, щоб зробити подібні URL-адреси ..../Users/1. Тоді ви зрештою отримаєте унікальне ціле значення.

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

З цієї причини дизайн може бути адаптований. Природний ключ стає альтернативним ключем (УНІКАЛЬНИЙ, НЕ НУЛЬНИЙ), і ви використовуєте сурогатний / штучний / технічний ключ як основний ключ, який може бути автоматичним збільшенням у вашому випадку.

запитав systempuntoout,

Що робити, якщо хтось хоче змінити свою електронну адресу? Чи збираєтесь ви також змінити всі зовнішні ключі?

Ось для чого це каскад .

Ще одна причина використання числового сурогатного ключа в якості основного ключа пов'язана з тим, як працює індексація на вашій платформі. Наприклад, у InnoDB MySQL, наприклад, у всіх індексах таблиці є попередній ключ до них, тому ви хочете, щоб ПК був якомога меншим (для скорочення та розміру). Також пов'язано з цим, InnoDB швидше, коли первинний ключ зберігається в послідовності, і рядок не допоможе там.

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

Так, це поганий первинний ключ, оскільки ваші користувачі захочуть оновити свої адреси електронної пошти.

так, краще, якщо ви замість цього використовуєте ціле число. ви також можете встановити свій стовпець електронної пошти як унікальне обмеження.

подобається це:

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

Ще одна причина, чому цілий первинний ключ кращий - це посилання на адресу електронної пошти в іншій таблиці. Якщо адреса сама по собі є первинним ключем, то в іншій таблиці ви повинні використовувати її як ключ. Таким чином ви зберігаєте електронні адреси кілька разів.

Я не надто знайомий з постгресами. Первинні ключі - велика тема. Я бачив кілька чудових питань та відповідей на цьому сайті (stackoverflow.com).

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

дещо читаючи тут і тут.

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

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

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

Додавання поля як унікального коштуватиме порівняння рядків лише при вставці в цю таблицю, а не при виконанні перевірок обмежень приєднання та зовнішніх ключів.

Звичайно, ви повинні зауважити, що додавання будь-яких обмежень до вашої програми на рівні бази даних може призвести до того, що ваш додаток стане негнучким. Завжди приділяйте належну увагу, перш ніж зробити будь-яке поле "унікальним" або "недійсним" лише тому, що вашій програмі потрібно, щоб воно було унікальним або непорожнім.

Використовуйте GUID як первинний ключ ... таким чином ви можете генерувати його зі своєї програми, коли ви робите INSERT, і вам не потрібно отримувати відповідь від сервера, щоб дізнатися, що таке первинний ключ. Це також буде унікальним для всіх таблиць і баз даних, і вам не доведеться турбуватися про те, що станеться, якщо ви обріжете таблицю одного дня, і автоматичне збільшення збільшиться до 1.

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

Як зазначає @HLGEM, "Jsmith@somecompany.com може легко належати Джону Сміту через рік і Джулії Сміт через два роки". у такому випадку, якщо Джон Сміт захоче вашої послуги, ви або повинні відмовитися від використання його електронної адреси або видалити всі ваші записи, що стосуються Джулії Сміт.

Якщо вам доведеться видалити записи, і вони стосуються фінансової історії бізнесу, залежно від місцевого законодавства, ви можете опинитися в гарячій воді.

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

Можливо, вам доведеться розглянути будь-яке застосовне законодавство щодо регулювання даних. Електронна пошта - це особиста інформація, і якщо ваші користувачі є громадянами ЄС, наприклад, відповідно до GDPR, вони можуть доручити вам видалити їх інформацію зі своїх записів (пам'ятайте, що це стосується незалежно від того, в якій країні ви перебуваєте).

Якщо вам потрібно зберегти саму запис у базі даних для референтної цілісності або історичних причин, таких як аудит, використання сурогатного ключа дозволить вам просто НУЛЮВАТИ все поле персональних даних. Це очевидно не так просто, якщо їх особисті дані є основним ключем

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

ви повинні використовувати цілий первинний ключ. якщо вам потрібен унікальний стовпець електронної пошти, чому б вам просто не встановити унікальний індекс для цього стовпця?

Якщо у вас є первинне значення non-int, то для великих даних вставки та завантаження будуть дуже повільними.

первинний ключ повинен вибирати статичний атрибут. Оскільки адреси електронної пошти не є статичними і їх можна ділитися декількома кандидатами, тому не дуже корисно використовувати їх як основний ключ. Більше того, адреси електронної пошти - це рядки зазвичай певної довжини, які можуть бути більшими за унікальний ідентифікатор, який ми хотіли б використати [len (email_address)> len (unique_id)], тому це потребує більше місця і навіть гірше, що вони зберігаються кілька разів як зовнішній ключ . А отже, це призведе до погіршення продуктивності.

Це залежить від столу. Якщо рядки таблиці містять адреси електронної пошти, то найкращий ідентифікатор - це електронна пошта. Якщо ні, то електронний лист не є хорошим ідентифікатором.

Якщо ви просто вимагаєте, щоб повідомлення електронної пошти було унікальним, ви можете просто створити унікальний індекс за допомогою цього стовпця.

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

не використовуйте електронну адресу в якості основного ключа, зберігайте електронну пошту як унікальну, але не використовуйте її як основний ключ, використовуйте ідентифікатор користувача або ім'я користувача як основний ключ