Добрый вторник!

Вопрос, мистяне, как вообще лучше организовать хранение и поиск строковых данных (акцизы, коды и т.д.). которые будут сливаться в одну базу.

Например несколько миллионов записей будут, строки длиной до 150.

1)Мне нужно их с кучи баз сгружать в одну, записывать куда-то
2)Отправлять запросы на поиск - была ли уже где-то такая строка, желательно с датой-базой и т.д.
Раз в полгодика чистить

Вопрос как лучше хранить эти строки - в регистре сведений? Включать индексацию?
В Рознице 3 например акцизы - это справочник, и уже он как поле в регистре сведений

внешняя бд, не 1С

(0) Легкии справочник с неиндексируемым реквизитом, в котором хранится код маркировки (твои 150 символов), индексируемый хэш поиска.
И регистр сведени, независимый и неподчиненный, в котором первое измерение - ссылка на этот справочник.

Работает на сотнях миллионов записей. Без деградации и избыточности. И паралельно.

(2) 1. бэкапы делать неудобно, размер
2. иногда требуется для разных систем, нужна внешняя

или выносить в отдельную миниконфу с публикацией hs или проще сразу (1)

(2)А можно глупый вопрос, что такое индексируемый хеш поиска?
Это в конфигураторе можно настроить или в бд лезть? МССкуль

В реквизите знаю что можно ставить индексировать или нет, а это с хешем поиска где делается?

(4) Из кода марки извлекаешь хэш md5, он как раз 16 байт, его засовываешь в реквизит
"ХэшПоиска" с типом УникальныйИдентификатор и его индексируешь. В ПередЗаписью() можешь делать. Потом ищешь по нему.
Да, труднее запросы делать, надо готовить хеши перед запросом.

Коллизий хеша не было на десятках миллионов, но, у меня марки 150 символов с уникальным криптохвостом, как это будет работать на калечных марках ЧЗ - я не скажу.

Либо тупо засовывай код марки в индексируемый реквизит, я засовывал в наименование, оно как раз 150 символов. Да, расход места на диске будет больше, в 2 раза, но можно не парится с хешами. По быстродействию я, кстати, не сравнивал, и так и так работает быстро.

md5 хеши лучше делать ВК-шкой, она раз в 10 быстрее работает, чем упоротое ХешированиеДанных от 1С, даже с учетом передачи данных в ВК и обратно.

(5)марки от ЧЗ в основном, да. Гребаные наркоманы, не могли даже все в верхнем регистре сделать, считывает как повезет.  И на сигареты додумались QR сделать 8х8 мм, хотя например на молочке он раза в 4 больше

(7) ЧЗ марки - небольшие по длине - я бы с ними не парился с хешем.

(8) Я бы с этим поспорил, первоначальные символы зачестую идентичны, т.е. дерево поиска будет не сбалансированное.
Можно использовать криптохвост, а он сейчас всегда в конце марки, чем не хэш?
Символов 6 должно быть достаточно...
Идеальных попадений меньше, но можно и так, для ускорения загрузки.

(9) Я сталкивался с ЧЗ несколько лет назад, уже не помню че там было. GTIN вроде вначале у них идет, одинаковый на позиции. Тогда - да, вы правы. Но я бы забил - теряется универсальность.

А индексация всего поля чем грозит? Поиск по идее быстрый будет, но место сжирать?

(11) Поиск теоретически, по 150 символам (300 байтам) будет менее быстрым, чем по 16 байтам, но это крайне не критично, есть другие узкие места.
Ну и размер индекса примерно равен 1.2*размер данных. Индекс на 300 байт данных будет весить 360 байт. Индекс на 16 байт будет весить 19 байт.
Смех смехом, но потом, когда данные наберете, ощутите.

(12)Ну по идее то если вот поле со всей маркой - разное, то хеш разный же тоже должен быть? Попробую с хешем

(13) Почитайте про коллизии хэшей.

(11) Обычно индекс это b-tree https://ru.wikipedia.org/wiki/B-дерево
Но там же все будет засунуто, и засунуто не оптимально (судя по структуре наших марок)...
По хэшу будет ощутимо быстрее, т.е. первый проход sql сделает по хэшу, второй уже по марке без хэша, но их не много найдется, (в зависимости от хэша, вычисление хэша тоже не бесплатное).
И это огромная экономия пространства базы.

(14) Да начхать на коллизии, надо искать сначала по хэшу, потом уже по марке.

(15) "Да начхать на коллизии, надо искать сначала по хэшу, потом уже по марке."
Допроверка? И пусть в базе 2 записи с одинаковым хешем?
Сук, как я не додумался.

хэш это как ГУИД получается, тоже может теоретически встретится одинаковый?

(16) Так я проверял, оно так и работает!
Ну это если sql не захочет сначала по марке проверять, а потом по хэшу, но это маловероятно...

(17) Вариантов реализации хэшей есть 100500, но ты прав, он совпадает и совпадает иногда гарантировано, в зависимости от длины хэша, а вот ГУИД почти всегда уникален, но иногда и он может совпасть.

(16) Бывает

(19)+ Причем возможно несколько хэшей сделать, для наборов измерений по которым ищем

(20) Согласен, но это модет быть и изилишетсвом, генерить SHA 512 на ключ строки 150 байт, это будет работать, но так себе...
Надо подобарть минально достаточный ключ хэша, но это уже делатается подлором.

(21) учитывая что криптохвост почти случайный - можно даже хэш взять простейший через пропуск символов

(0), (6) "но можно не парится с хешами" - с отдельным хешем для поиска в любом случае придется запариться, т.к. некоторые коды отличаются только регистром символов, а условие на строку в запросе работает без учета регистра.

+(23) По рукам бы надавать за такое разрабам в ЦРПТ.

(0) Ну нормально в регистре сведений.

(12) Для ЧЗ отказался от md5 и хэшей в привичном виде как раз из-за размера таблицы.
Ищу по марке + своему хэшу.

Хэш: берем из марки только символы верхнего регистра (это будет 1), остальные символы 0.
Из 01GTIN21aaaAaaa получаем 0001000 (считаем за двоичную систему).
Далее 0001000 переводим в 10-ную систему.
Далее 10-ную систему в 96-ную
Шаблон = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЬЫЪЭЮЯ!@#$%^&*()_-=+{}[]\|/,.:;'""><"

Хэш почти не занимает места.

(26) Обычно это 0-2 символа, редко больше

(4) можно без хэшей, будет медленнее...но  если нужна "взрослая" скорость бери ClickHouse или Vertica