Как выбрать первичный ключ в базе данных на примере человека

Что проверяют

Умеете ли вы отличить «уникальное сейчас» от «уникального навсегда» и понимаете ли, что у человека нет идеального естественного идентификатора. Следом обычно спрашивают, как тогда не завести одного и того же человека в базу дважды.

Как отвечать

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

• уникальность: двух строк с одним значением быть не может;
• обязательность: NULL недопустим, значит атрибут должен быть у каждого человека с первого дня;
• стабильность: значение не меняется, иначе придётся каскадно переписывать все внешние ключи;
• компактность: ключ копируется в каждую связанную таблицу и в каждый индекс по ней.

Потом пройдитесь по кандидатам. Паспорт меняют по возрасту, при утере и смене фамилии, у иностранцев и детей документы другие. СНИЛС и ИНН есть не у всех. Почта и телефон меняются. ФИО с датой рождения не уникальны даже в пределах одного города. Вывод: естественного ключа для человека нет, берём суррогатный.

Суррогат это bigint с GENERATED ALWAYS AS IDENTITY или UUID. UUID удобен, когда записи создаются в нескольких системах и потом сливаются, а UUIDv7 растёт по времени, поэтому новые записи ложатся в конец индекса, а не в случайные страницы. Естественные атрибуты при этом никуда не деваются: на пару «тип документа, серия и номер» ставится UNIQUE, это альтернативный ключ, который и защищает от дублей.

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

Где спотыкаются

Называют паспорт «неизменным» идентификатором. Интервьюер сразу спросит про замену в 20 и 45 лет, и ответ рассыпается.

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

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