Чтобы отличать записи в реляционной БД, у них должны быть уникальные поля. Это может быть как одно поле, которое для всех записей принимает разные значения, так и целый набор.
Любой набор колонок, в которых значения будут уникальны для всех записей, называется суперключом. Имеется ввиду группа значений по всем колонкам, а не в каждой по отдельности.
Если же, выкидывая из такого набора любую колонку, мы теряем уникальность - это называется потенциальный ключ. То есть, потенциальный ключ - уникальный набор колонок, который нельзя уменьшить.
В БД может быть много потенциальных ключей, и поэтому мы выбираем один из них как основной, который мы будем использовать - это первичный ключ (primary key, PK, ПК). То есть:
• Первичный ключ в таблице всегда один.
• Первичный ключ - это не обязательно одна колонка (простой ключ), а может быть и группа из нескольких колонок (составной или композитный ключ).
• Даже если у нас простой ключ, он не обязательно называется
id, имя колонки может быть любым, хотя стоит придерживаться стандартных названий.Иногда мы записываем в БД данные, в которых естественным образом уже есть потенциальные ключи, мы выбираем из них один как первичный - это естественный ключ. Но иногда потенциальных ключей сразу не наблюдается или они какие-то неудобные для использования (никто ведь не захочет везде таскать первичный ключ из 5 колонок?), в этом случае под первичный ключ заводят отдельную колонку со сгенерированными уникальным значениями - это суррогатный ключ.
Суррогатный ключ можно генерировать разными способами. Два наиболее популярных - псевдослучайный (например, с помощью
uuid4) и автоинкремент.• Псевдослучайный ключ позволяет использовать его ещё до обращений в БД, что бывает полезно. Его использование усложняет перебор ключей и определение количества записей, что может быть важно. Но из-за алгоритма генерации может быть неэффективен для поиска в БД.
• Автоинкремент требует обращения в БД, которая в том или ином виде запоминает какие были уже выданы номера.
При использовании автоинкремента номера не обязаны идти по порядку и даже по возрастанию. С точки зрения целей использования первичного ключа это не требуется, поэтому для большей эффективности БД не пытается за этим следить. А конкретно есть несколько причин:
• При удалении записей номера освобождаются, но номера остальных записей не меняются. Если бы БД просматривала какие номера освободились, это заняло бы много времени.
• При конкурентных транзакциях будут сгенерированы несколько номеров одновременно. Но одна из транзакций может быть не зафиксирована и тогда номер не будет фактически использован. Следить за такими номерами тоже было бы достаточно не эффективно. Кроме того транзакции могут быть открыты и зафиксированы в разном порядке, что будет отличаться от порядка генерации ключей.
• При определенной настройке некоторые СУБД генерируют автоинкрементные PK не по одной, а несколько за раз и хранит внутри сессии. Тогда конкурентные вставки будут использовать номера из разных наборов, что сохранит уникальность, но нарушит порядок.
Дополнительные материалы
• https://ru.wikipedia.org/wiki/Нормальная_форма
• https://habr.com/ru/articles/572700/
• https://habr.com/ru/articles/747348/