Как выбирать первичные ключи в БД?

Question

[Olya_Ann]

Как выбирать первичные ключи для таблиц в БД ? Знаю, что есть такое понятие, как искусственные и естественные ключи. Предположим есть сущность "Отдел", у которой есть такие атрибуты как "Наименование" и "Дата создания". По идее, первичным ключом можно выбрать "Наименование", что обеспечит уникальность записей. Но часто всё-таки добавляют искусственный первичный ключ "Номер". Подскажите, почему так? Это как-то влияет на производительность? В качестве ключей в принципе лучше не выбирать текстовые поля? И ещё небольшой вопрос, влияет ли как-то на производительность составной первичный ключ, который может включать не два, а три атрибута (иначе уникальность не обеспечить)?

Comments

[Shavadrius]

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

Answer 1

[Александр Нестеров]

Но часто всё-таки добавляют искусственный первичный ключ "Номер".

Основная идея первичных ключей - неизменяемость и уникальность. В качестве ключа может использоваться, например, инвентарный номер или isbn, даже если содержит буквы/символы, т.к. он физически уникален и не изменяем. С другой стороны есть очень много вещей, которые могут меняться: фио, номера телефонов, логины. И если изменить это данные, то придется изменить их и во всех таблицах, которые ссылаются на эти данные. И чтобы избежать таких ситуаций и используют искусственные ключи.

Comments

[Olya_Ann]

Спасибо)

Answer 2

[hint000]

Но часто всё-таки добавляют искусственный первичный ключ "Номер". Подскажите, почему так?

В таком простом случае - например, потому, что начинающие программисты. Им так проще. Либо увидели где-то пример и бездумно копируют.

Хотя можно придумать пример посложнее. Пусть есть несколько филиалов и в разных филиалах отделы с одинаковыми названиями. Тогда составной ключ будет Филиал + Наименование, это уже не очень удобно и тогда появляется обоснованное желание добавить номер вместо составного ключа.
Здесь перечисляются преимущества ("причины использования") и недостатки:
https://ru.wikipedia.org/wiki/Суррогатный_ключ

Причины использования:

• Неизменность
  
• Гарантированная уникальность
  
• Гибкость
  
• Эффективность
  
• Упрощение программирования
  

Недостатки:

• Уязвимости генераторов ключей
  
• Неинформативность
  
• Склоняет администратора пропустить нормализацию
  
• Вопросы оптимизации
  
• Невольная привязка разработчика к поведению генератора ключей в конкретной СУБД
  

Короче, использовать можно и нужно, если понимать, что в конкретном случае преимущества сильнее, чем недостатки. Без понимания тоже можно использовать, но будет лотерея: либо лучше, либо хуже. Потом придёт сеньор и отрефакторит.

Comments

[Olya_Ann]

Спасибо)