В системе есть разнообразные объекты.
Для каждого экземпляра объекта имеется уникальный (в пределах всей системы) ID::INT8, по которому может быть установлен его тип.

Для некоторых объектов: коробки с товаром, стеллажи, ячейки хранения и пр. хотелось бы генерить уникальные же штрихкоды. Совместимость данных в ШК с какими-либо системами (EAN etc) не важна.

Прямое решение - генерить ШК в виде текстовой строки, в которой написан его ID::INT8 и кодировать, к примеру CODE39.
Уникальность ID уже реализована сопутствующей логикой при создании объекта.

Одно "НО". Хотелось бы в контексте интерфейса пользователя проверять формальную валидность считанного ШК. Например, для "закрытия" коробки с товаром нужно считать ШК коробки, а не ШК накладной, складской ячейки или пачки сигарет. Чтобы проверить, что это действительно коробка, нам придется делать запрос к БД, что явно недешовое решение. Особенно если задумчивый кладовщик будет с наслаждением тыкать сканером в посторонний предмет раз в секунду.

Усложненное решение - генерить ШК в виде строки с префиксом, однозначно связанным с типом объекта. Например "box" & [boxid], "shelvse" & [shelvseid]. ШК можно хранить не в дереве объектов, а в таблице из предметной области (коробки, ячейки и пр.).
Так мы получаем возможность проверять пользовательский ввод в интерфейсе, отсекая явно ложные операции. Минус - придется делать поиск уже не по INT8, а по текстовой строке.

Какой подход окажется лучше с точки зрения быстродействия?

Bogdanov Andrey
Сделайте префиксы числовыми (это улучшает качество печатаемого ШК) и фиксированной длины. Тогда восстановить по ШК INT8 не составит труда. И поиск будет идти все также быстро.

Т.е.
1) ШК текстовый, типа [prefix]::INT4 & "-" & [objectID]::INT8,
типа вот так "1001-123456789012345678"
2) клиентское приложение выделяет из строки [prefix] и [objectID]
3) по префиксу делает предварительную проверку
4) select к БД делаем уже по [objectID]::INT8

Спасибо, действительно удобный вариант!

Bogdanov Andrey
б) Я тут уже где-то писал - повторю. Штрих коды начинающиеся с двойки зарезервированы для внутреннего использования компаниями. Поэтому начинайте префикс с двойки. В этом случае вы легко отловите "задумчивого кладовщика", который вместо стеллажа сканирует штрих-код с недопитой бутылки водки.

Как я понимаю, под это определение попадают логистические коды для транспортной упаковки ITF-14. Они могут начинаются с "2".

Не стоит ли построить строку с простой контрольной суммой (типа md4), которой дополнять свой код? Это минимизирует коллизии с целочисленными кодами ITF-14 от транспортных компаний.

Следовало бы, конечно, скататься на склад и посканировать все коды, которые наносят поставщики и перевозчики на наш груз, но хочется предусмотреть и "теоретичекую сторону задачи".

Кстати,
если мой числовой префикс совпадет с каким то префиксом ITF-14 (и EAN внутри), то у меня возникнет коллизия с целым диапазоном номеров!

Bogdanov Andrey то шанс нарваться на двойку выше.
Вот именно этого то я и боюсь. Самое противное, что если чей-то EAN (начиная со второй цифры после двойки), или внутренний код совпадет с моим префиксом, то я получу целый диапазон коллизий!

Хочется ввести что-то случайное (hash) в штрих=код, чтобы я всегда мог его вычислить и проверить, нашей ли системой сгенерен код.

Но,
19 десятичных разрядов на INT8
3 десятичных разряд на префикс

Для контрольной суммы вообще места не остается. Очень длинный код получается.
Можно делать текстовый код и выгонять в его в шестнадцатиричке с битом четности, ловить ошибки преобразования.

Или ну его нафиг.
Как вы думаете?