UUID или последовательный ID: как выбрать контракт идентификатора
Сравнение способов выдачи идентификаторов без универсальных обещаний скорости: где создаётся ID, как повторяется импорт и кто проверяет уникальность.
Выбор между UUID и последовательным числом начинается с процесса создания записи. Если все записи выдаёт одна база, штатный счётчик может покрывать задачу. Если идентификатор требуется до обращения к ней или создаётся в нескольких независимых источниках, рассмотрите UUID. Сам по себе длинный случайный ключ не делает приложение безопаснее или быстрее.
Сначала запишите требования: где появляется ID, кто отвечает за уникальность, как переносится запись между системами и что происходит при повторной отправке. Это полезнее, чем выбирать тип по популярности.
Разделите три назначения
Внутренний ключ нужен для связей хранения. Публичный идентификатор нужен API или ссылкам. Номер для человека нужен поддержке и поиску в интерфейсе. Эти значения могут совпадать, но не обязаны.
Например, синтетическая запись может иметь внутренний id=42, публичный UUID и номер DRAFT-0042. Префикс и оформление номера не означают отдельную схему безопасности. Если приложение хранит два ключа, каждый имеет назначение и ограничения; добавлять второй «на всякий случай» не нужно.
Ключ не является датой создания. Для сортировки и отчётного периода храните отдельное временное поле с контрактом. Порядок чисел или случайных строк не заменяет явные правила хронологии.
Когда подходит штатная последовательность
Если одна база создаёт записи и связь нужна после вставки, используйте её штатную возможность identity/sequence. Не вычисляйте следующее значение как «максимальный ID плюс один» в приложении: параллельные запросы могут выбрать одно число.
В PostgreSQL identity автоматически выдаёт значение, но уникальность обеспечивается отдельным PRIMARY KEY или UNIQUE. PostgreSQL: identity columns, документация текущей версии, проверено 05.10.2026.
Не требуйте от технического ID последовательности без пропусков, если система не обещает её явно. Удаление записи, отклонённая операция и иные события жизненного цикла могут сделать счётчик неудобным бизнес-номером. Требование непрерывной нумерации — отдельная задача, не аргумент для ручного счётчика.
Когда полезен UUID
UUID позволяет присвоить идентификатор до сохранения записи в общей базе. Это удобно для подготовленных объектов, импортных пакетов и независимых источников. Конкретная версия определяет способ формирования; UUID v4 использует случайную или псевдослучайную составляющую. RFC 9562, раздел 5.4, май 2024; проверено 05.10.2026.
Генератор UUID Neraviko выдаёт v4. Для обычной генерации оставьте seed отсутствующим; параметры count=1, uppercase=false дают массив output.values из одной строки. Версии v5/v7 переключателем здесь не выбираются.
Для статьи формат проверен на синтетическом значении:
07f7f6ad-b06e-4aaa-8e69-15c2c6d1508c
Оно получено отдельно в seeded тесте, не предназначено новым рабочим записям. Проверка показывает version=4 и применяемый RFC variant; она не доказывает уникальность в вашей базе.
Повторная отправка важнее вида ключа
Возьмём искусственную импортную запись с внешним ключом source:A17. При каждом повторе импортёр может заново получить UUID и создать дубль той же сущности. Выдача уникального технического ключа не ответила на вопрос, существует ли исходная запись уже.
Согласуйте устойчивый внешний ключ либо отдельный ключ идемпотентности. Присвоенный UUID сохраняйте вместе с результатом сопоставления. У последовательного ID та же задача: новый номер при повторе не означает новую бизнес-сущность.
При объединении двух источников локальные числовые ID могут совпасть. Решение — явное пространство источника, таблица соответствий или согласованный независимый ID. UUID снижает потребность согласовывать общий счётчик, но ограничение уникальности и обработку конфликта оставьте в хранилище.
Скорость и доступ проверяйте отдельно
Размер ключа, индекс, порядок вставок и тип хранения влияют на конкретную базу. Универсального вывода «UUID всегда медленнее» или «число всегда лучше» из формата не следует. Если это значимо, сравните реальные операции на своей схеме и объёме данных, без переноса чужих цифр.
UUID в ссылке не заменяет проверку прав. Пользователь, получивший чужой корректный ID, всё равно должен получить отказ согласно политике приложения. Непредсказуемость значения и авторизация — разные свойства.
Для решения достаточно пяти пунктов: место выдачи ID, момент его появления, правило уникальности, повторный импорт и формат публичного API. Зафиксируйте их, затем выберите минимальный подходящий механизм. Веб-генератор — серверный инструмент для проверки формата и небольших наборов; сырые запросы и результаты по контракту не сохраняются и не логируются по умолчанию. Для потока рабочих ID генерацию встраивают в существующее приложение.