Стоит ли делать составной первичный ключ?

#jpa #база_данных #orm

Изучаю вот этот вопрос, там такая фраза в ответе


  Composite primary keys typically arise
  when mapping from legacy databases
  when the database key is comprised of
  several columns.


Я правильно понимаю, что legacy это практически синоним слову "устаревший"?
Если так, то стоит ли, при разработке нового приложения и новой базы данных, делать
составные ключи? Или просто добавить ещё один столбец, который по сути ничего не будет
делать, ведь всю работу с бд обычно выполняют фреймворки?
    

Ответы

Ответ 1

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


Ответ 2

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

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

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

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

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

Как правило, при наличии такого поля нет никакого смысла в составных ключах.



Тем не менее, иногда составные ключи бывают полезны. Вот эти случаи:


Таблицы-связки для отношений "много ко многим". Обычно такие таблицы создаются и
управляются библиотеками ORM самостоятельно - но иногда приходится создавать их отдельно.
В таких таблицах естественным ключом является вся запись целиком - и нет никаких причин
создавать отдельный суррогатный ключ.
Некоторые дочерние подобъекты, не имеющие смысла в отрыве от родительского. Если
мы делаем систему для тестирования учащихся - то иногда имеет смысл обращаться к ответу
на вопрос как к 5му ответу на 147й вопрос - а не к 3423му ответу вообще. А иногда наоборот.
Использование отношений в БД для дополнительной проверки целостности. Существует
так называемая доменно-ключевая нормальная форма, в которой любые ограничения на данные
реализуются в формате внешних ключей. В таком случае иногда имеет смысл включать дополнительные
поля в первичный ключ.


Ответ 3

Полагаю, перевод по смыслу: "Составные первичные ключи обычно возникают при сопоставлении
с существующими таблицами базы данных, когда ключ таблицы состоит из нескольких столбцов."
legacy здесь это практически синоним слову "существующий".
При разработке новой таблицы теоретически не следует создавать избыточность информации
новым ключевым полем если существующая в ней комбинация внешних ключей(или других полей)
уже является уникальным ключом.
Но практически поиск по дополнительному полю уникального ключа может быть быстрее
или субъективно проще для разработчика и таким образом иметь смысл для достижения необходимого
результата :)