Антипаттерн: как не надо генерировать новые идентификаторы

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

Не буду описывать весь спектр вариантов. Однако худшее, что можно придумать —сделать view, в котором будут объединены все эти таблицы, а потом при генерации нового идентификатора делать выборку вида:

SELECT MAX(id)
FROM view

Затем, например, прибавлять к полученному результату 1 или ваш шаг изменения номера.

К каким проблемам может привести такая, на первый взгляд, простая, а значит, возможно, и наиболее эффективная идея?

Смотрите, как только ваше приложение дорастёт до небольшой конкуретности запросов на вставку, для которых нужно будет генерировать новые идентификаторы, вы увидите неприятные последствия своего решения: 1) у вас могут возникнуть дубликаты идентификатора; 2) если вы сделали защиту от дубликатов, могут возникнуть ошибки при попытке вставить одинаковый идентификатор.

Какие есть варианты?

Для генерации сквозного идентификатора лучшим выбором будет использование последовательности. Во многих СУБД (например, PostgreSQL, Oracle, MS SQL) для этого предусмотрен отдельный объект. Работа с такими объектами поддерживается на уровне СУБД и существуют специальные средства получения нового элемента, так что вы будете надёжно защищены от ситуации, когда параллельные запросы, вдруг, получают одинаковый следующий идентификатор.

Узнать больше можете на наших курсах по СУБД. Набор в группу уже начался, не пропустите!