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

💬 Если простого ключа нет, почти всегда можно придумать составной. Например, здесь автор приводит в пример студенческий проект — базу данных для сайта со списком 50 лучших ресторанов, где в качестве ключа предложили использовать сочетание названия заведения и города. Уже можно догадаться, какие минусы есть у такого подхода — чем больше город, тем больше вероятность, что там заведутся два ресторана с одинаковыми названиями. Но для небольшого набора данных, он вполне применим.

Кроме вопросов к уникальности, которые почти неизбежно возникнут при работе с большим датасетом, есть и другие сложности.
🔵 Многие данные, которые можно было использовать в качестве первичного ключа, могут со временем меняться — например, телефон, email, номер и серия паспорта. В той же статье автор приводит пример, когда во время техосмотра выяснилось, что у его машины неправильный VIN. Проблема решилась тем, что механик просто исправил его в системе. То есть даже такие, казалось бы, неизменяемые вещи, как VIN или серийный номер могут в какой-то момент измениться.
🔵Никто не застрахован от ошибок и опечаток, и чем больше датасет, тем выше вероятность, что кто-то неправильно запишет номер или опечатается в собственном имени. Будет неприятно, если такая ошибка закрадется в поле, которое используется как первичный ключ.
🔵 Искусственный (суррогатный) ключ помогает избежать этих проблем, а еще в теории — упростить запросы и внесения изменений в таблицы.

Хотя у них тоже есть минусы — неинформативность или сам факт создания каких-то дополнительных сущностей в таблице вместо того, что навести в данных порядок и обеспечить их точность, актуальность и уникальность.

А какой вариант вам ближе? 👀