Дубли номеров заказов: уникальность важнее красивой очереди
Дубли номеров заказов при одновременном создании нужно устранять правилом выдачи и ограничением уникальности в согласованной области, а не поиском последнего номера на экране. Отдельно храните идентичность заказа, человекочитаемый номер и обозначения партнёров. Последовательность без пропусков — другое требование: обычный генератор уникальных значений её не гарантирует.
Два оператора видят один последний номер
Учебный пример: в списке последний заказ имеет номер 1042. Два сотрудника почти одновременно создают разные заказы. Если программа берёт максимум и прибавляет единицу без согласованной защиты, оба действия могут выбрать 1043. Сначала разберём эту последовательность, а не внешний вид номера.
- Первая операция читает последний видимый номер 1042 и вычисляет 1043. Она ещё не сохранила окончательный заказ.
- Вторая операция успевает прочитать тот же 1042 и тоже вычисляет 1043. У неё нет основания знать о незавершённом действии соседа.
- Первая операция сохраняет свой заказ. Если существует только проверка в интерфейсе, она могла давно закончиться.
- Вторая пытается сохранить другой заказ с тем же обозначением. Система должна предотвратить конфликт по выбранному правилу и корректно завершить обработку, а не создать неоднозначность.
Повторная проверка «свободен ли номер» тоже не решает задачу, если между проверкой и записью остаётся то же окно. Проектируйте механизм выдачи вместе с защитой хранения. Нужна гарантия на реальном пути создания, включая фоновые операции и импорт, а не только на одной форме менеджера.
Какие обозначения нельзя смешивать
При разработке CRM сначала составьте карту идентификаторов. Человек может назвать короткий номер по телефону, система должна надёжно связать все записи, а партнёр присылает свой внешний номер. Это разные роли данных, даже если в простой версии они выглядят одинаковыми.
| Обозначение | Кто задаёт | Область уникальности | Изменение | Действие при конфликте |
|---|---|---|---|---|
| Внутренняя идентичность заказа | Собственная система по выбранной модели | В пределах согласованного хранилища и архитектуры | Не менять ради красивой нумерации | Разобрать нарушение целостности, не склеивать заказы |
| Номер для сотрудника и клиента | Правило компании | Например, организация и период либо единая серия | Только по явной согласованной процедуре | Не сохранять два разных заказа с одинаковой полной областью |
| Номер заказа партнёра | Внешняя система | С учётом конкретного источника и его правил | Сохранять происхождение изменения | Проверить источник, не считать чужие серии одной |
| Идентификатор повторяемого запроса | Клиент или интеграционный слой по контракту | В области согласованного действия | Не использовать как свободно редактируемый номер заказа | Найти результат прежней команды вместо слепого создания копии |
Область уникальности записывают полностью
Если филиалы имеют отдельные серии, номер 1043 может встретиться в каждом. Тогда сотруднику и внешнему обмену нужен полный контекст: к какой серии относится обозначение. Если бизнес ожидает единый поиск по номеру во всей компании, разные локальные серии без различимого префикса создадут путаницу, даже когда база технически считает каждую комбинацию уникальной.
При годовом начале новой серии определите, какая дата задаёт период и что происходит с запоздалым заказом или документом, введённым задним числом. Не используйте случайную дату браузера как общее правило компании. Настройка нового периода должна быть одинаково понятна онлайн-форме, импорту и другим разрешённым путям создания.
В документации PostgreSQL по ограничениям уникальность может задаваться для столбца или комбинации столбцов. Для вашего процесса нужно правильно выбрать эту комбинацию и обязательность её составляющих. Само наличие ограничения на каком-то поле не доказывает, что защищена именно бизнес-область номера.
Генерация значения и защита записи дополняют друг друга
В описании последовательностей PostgreSQL nextval выдаёт значения атомарно при конкурентных обращениях. Это конкретный механизм базы, а не повод обещать правильность любого пользовательского шаблона номера. Обрезание, объединение серий и ручное изменение состояния генератора могут создать отдельные проблемы, которые нужно исключить в реализации.
В задании укажите, как система реагирует на неожиданный конфликт: останавливает действие с понятной ошибкой или безопасно повторяет выделение по согласованному алгоритму. Повтор не должен дважды выполнить связанные бизнес-действия. Заказ считается созданным только после принятого результата сохранения, а предварительно показанное обозначение нужно честно отличать от окончательного.
При интеграции через API передавайте назначенный номер и устойчивую связь с заказом, а не пытайтесь восстановить его из общего счётчика. Не публикуйте наружу неподтверждённое значение как окончательный результат. Партнёру нужен способ сопоставить ответ с конкретным действием, особенно после потери соединения.
Почему пропуск не равен потерянному заказу
Документация PostgreSQL отдельно объясняет, что значение sequence не возвращается для повторного использования при откате вызывающей транзакции. Поэтому возможны пропуски. Из разрыва между 1043 и 1045 нельзя без дополнительных данных заключить, что заказ 1044 существовал и был удалён. Проверять нужно журнал операций и сохранённые заказы.
Не устраняйте такой пропуск перестановкой всех последующих номеров. На них могут ссылаться сотрудники, файлы и внешние системы. Если бизнес действительно требует непрерывную регистрацию определённых документов, это отдельная постановка с другими ограничениями и проверкой применимых правил. Эта статья о нумерации рабочих заказов, а не универсальной схеме кассового или налогового учёта.
Три проверки, которые часто забывают
Импорт старой базы
Проверьте конфликт старых и новых серий до запуска. Сохраните внешнее происхождение номера и не объявляйте совпадение достаточным основанием объединить разные заказы. При переносе может потребоваться таблица соответствий, чтобы прежние ссылки оставались объяснимыми. Это входит в требования к автоматизации учёта.
Удаление и отмена
Решите, что происходит с обозначением отменённого заказа и кто вправе его менять. Повторное использование номера может сделать старую переписку неоднозначной. Если принято сохранять историю, отсутствие заказа в обычном списке не должно означать, что обозначение свободно для другой сущности.
Разные заказы и повтор одной команды
Совпадение номеров разных сущностей — ошибка нумерации. Два запуска одной команды после сетевого сбоя — задача повторяемости действия. Они могут проявляться одновременно, но требуют разных проверок. Успешная защита от одинакового номера ещё не доказывает, что повторный запрос не создал второй заказ с другим номером.
Приёмка по журналу событий
Попросите разработчика продемонстрировать на учебных данных одновременное создание разных заказов, повтор одной команды, импорт и смену периода. Сверьте итоговые сущности, их идентичность и полные номера. Затем имитируйте отклонённое сохранение и объясните наблюдаемый пропуск по журналу. Результат должен быть понятен без ручной перенумерации базы и без догадок по последней строке списка.
Вопросы и ответы
Как организовать нумерацию заказов?
Определите область уникальности, момент назначения и различие внутреннего идентификатора и видимого номера. Механизм выдачи и ограничение хранения должны работать для всех согласованных путей создания.
Что означает duplicate order number?
Это сообщение о повторном номере в области, где система ожидает уникальность. Нужно отличать конфликт разных заказов от повторного запроса создания одной и той же сущности.
Почему в PostgreSQL sequence появляются gaps?
Полученное значение последовательности не обязано возвращаться после неуспешной транзакции, поэтому возможны пропуски. Они сами по себе не доказывают потерю заказа и не требуют переписывать последующие номера.