Идентификатор записи в БД: Целое число против UUID

Для нас ответ на вопрос «что же использовать в качестве идентификатора записей в БД?» уже давно не стоит, за явным преимуществом победил UUID. Эта небольшая заметка о причинах, послуживших причиной к отказу от использования целого числа в качестве идентификатора.

Впервые отказаться от целочисленного идентификатора пришлось при работе над проектом Dodo IS (Информационная система Додо пиццы), когда на горизонте замаячили микросервисы, нагрузка, шардирование и прочие непонятные термины. До этого в качестве идентификаторов использовались именно целые числа, которые генерировались БД при помощи автоинкремента. При таком подходе невозможно было разнести какую-либо таблицу по разным серверам, потому что идентификаторы просто начали бы дублироваться. Получалось бы что-то типа такого.

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

Но у этого перехода был еще один очень положительный момент, который заставил нас использовать UUID всегда и везде. Хотя казалось бы, не все проекты дойдут до какой-то значительной нагрузки. Большой проблемой автоинкрементарного целочисленного идентификатора был тот факт, что появлялся он только после добавления записи в таблицу. Представьте себе запись информации о заказе в БД, даже в самом простом варианте, когда должна быть добавлена запись в таблицу заказов (orders), а так же записи в таблицу позиций этого заказа (orderItems), которые, очевидно, должны иметь поле orderId. В таком случае приходилось последовательно сначала добавлять запись в orders, получать идентификатор последней вставленной записи, а уже потом добавлять в БД позиции. В реальности при создании заказа количество таблиц, в которые делались вставки, значительно больше двух, цепочки последовательных вставок становятся достаточно длинными.

Когда же вы используете UUID, то генерация идентификатора происходит в коде и уже перед выполнением запроса на вставку известен будущий идентификатор записи. Это позволяет избавиться от технических ограничений на параллельную вставку записей в связанные таблицы, запросы на вставку записей в таблицы orders и orderItems могут выполняться одновременно. Да, могут быть логические ограничения, которые не позволят это сделать, но это уже другая история. Мы с радостью забыли про существование функции last_insert_id (mysql) и спокойно используем UUID в почти всех наших проектах.

Вам также может понравиться...

Популярные посты