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

В базе 400 тыс. товаров. Артикул отдельный реквизит.
Задача: программно обходя файл с наименованиями, найти соответствующий ему товар, если такой есть.

Пока вижу только вариант, обойти в цикле все товары и сделать СтрНайти(НазваниеИзФайла,АртикулИзБазы)
100 тыс строк в файле, 400 тыс. товаров, даже не охота тестировать сколько это времени займет.

Есть ли идеи как это сделать быстро?

(0) https://wonderland.v8.1c.ru/blog/podderzhka-regulyarnykh-vyrazheniy-vo-vstroennom-yazyke/

(1) и что?
Все равно прийдется обходить в цикле все товары, и использовать регулярное выражение, которое наверное на порядок медленнее чем  СтрНайти

(0) напрашивается запрос с соединением по подобно, но может и зависнуть. Потестировать на небольших порциях.

(0)[В артикуле могут быть буквы, цифры, спецсимволы, пробелы, что угодно.]
это не артикул - беги оттуда

Чота возникают большие сомнения в том, что результат этой всей работы будет сколько-нибудь достоверным. А на объеме точно никто не проверит и ошибку не найдет. Про уникальность такого вот артикула из любых символов я вообще умолчу.

(0) списаться с людишками создавшими внешний файл и пусть артикул выводят в отдельный столбец.

(0) Быстрого алгоритма нет. Просто в 1С может быть еще медленнее.

Попробуй

1) Артикулы базы выгрузить в массив, одним запросом.
2) Файл с наименованиями собрать в таблицу значений.

Ну и цикл в цикле.
Через полчаса стопорнись отладчиком, посмотри на каком индексе массива артикулов находишься

(7) кстати, на больших объемах вместо массива не быстрее будет соответствие?

(8) Соответствие чего с чем?

На больших объемах быстрее будет представить таблицу файла в виде многострочного текст и искать там, но я пока не соображу, как нам использовать НомерПозиции, которую вернула СтрНайти() когда нам нужен НомерСтроки

(10) Ну теоретически можно каждую строку добить символами до фиксированной длины... Но это ж по каждому артикулу (которых 400 тысяч) искать в файле, плюс еще и наверняка будет по несколько вхождений...

Все, понял.

Через СтрНайти() находим позиции артикулов в тексте, складываем их в массив, в одном цикле.

Потом в одном цикле обходим текст и формируем соответствие НомерСтроки - ДиапазонПозиций (1 строка - 1 позиция по 10 позицию, 2 строка - 10 позиция по 18 позицию).

Потом в цикле привязываем номера артикулов к номерам строк текста.

Создать пустую базу 1с на SQL, добавить два справочника наименования и артиклы, загрузить туда данные. В запросе соединить справочники с условием СТРНАЙТИ — а там пускай алгоритмы SQL оптимизируют.

(0) >Есть ли идеи как это сделать быстро?

Потребовать от контрагента предоставлять файл с данными с выделенной колонкой артикул.

(14)+ Если это никак то использовать свои индексы

Например метод N-грамм (биграмм или триграмм думаю)

1. Все свои 400к артикулов разбить на N-граммы, будет три таблички артикулы|N-граммы|связи между артикул и N-грамма
2. Аналогично 100к входящих наименований разбиваем на N-граммы
3. Логично что все N-граммы артикула для подходящих наименований должны содержаться в этом наименовании?

(0) Какого формата файл?

(13) алгоритмы sql для like если не с начала поля там даже индексы не работают
оно помрет короче

(15)+ Для упрощения/ускорения можно увеличить длину N и сделать его переменным с уменьшением кол-ва вариантов
Для начала найти всевозможные символы(сочетания символов) "разделители"

Ну там " "/","/";"/"."/"-"/". "/", "/"("/")" и т.д.
Далее логично что разделяем наименования по разделителям - получаем слова и эти слова ищем в артикулах

Но разделители могут быть и внутри артикулов, поэтому слегка усложняется тем что сами артикулы тоже надо разделять на N-граммы и все же по ним искать

(18)+ разделители чтобы понятней:
" "
","
";"
"."
"-"
". "
", "
"("
")"
...

чем артикул отделен от текста?  если пробелаи, то разбирай строку на токены по пробелам, ищи каждый токен в артикулах.
Если может быть не отделен - то как подсказал Garykom, разделяnь на N-граммы, и по максимальному правдоподобию.

(0)
в линуксе

grep артикул имяфайла

(400 тыс строк быстро)

(21) в цикле по 400к артикулов где в имяфайла 100к строк?

(22)
не знаю, насколько быстро.
Быстрее будет,чем через СтрНайти() (цикл в цикле).

Поставить Redis, написать на питоне или ноде простенький скрипт загрузки в него всех данных, выгрузить туда же базу товаров из 1С и второй скрипт пусть перебором ищет, думаю пары минут хватит. Redis в оперативке хранит данные, а ключи индексирует - поиск дико быстрый

(24) муахаха

(24) Давай я тебе оплачу пару минут твоего времени по ставке 4к в час
Только вот если на 400к артикулов и 100к строк в документе с наименованиями твое решение за 5 минут не справится то уже ты платишь мне?

(23) Самое тупое решение в лоб но с возможно приемлемым быстродействием:

1. Находим варианты длин артикулов
2. Цикл но строкам, цикл по длинам артикулов, затем цикл скользящий скан подстроки (= длине артикула)
3. Ищем подстроки запросом среди артикулов

Кол-во запросов в цикле можно подсократить передавая разом пакет строк

(26) а ты на самом деле недооцениваешь такие решения

когда я в мейле работал, у нас была такая процедура как матчинг названий треков вконтакта с базой песен правообладателей, и там миллионы были артикулов и сотни тысяч записей, ежедневно
оно там лопатило на 5 серверах с кешами в редисе и еще прогревало индексы минут 15... но работало просто с адовой скоростью, база на несколько терабайт часа за два...400к и 100к это ерунда

(28) Я в курсе что распараллеливанием можно это все сильно ускорить
Тот же вариант (27) запустить в 50 или даже 100 потоков и вперед

(29) там не только распаралеливание, обработка в памяти тоже очень всё сильно ускоряет, особенно если выкинуть всякие фреймворки и ормы тормозящие

(30) Нечеткий поиск/сравнение на каком методе были?

(31)+ для "матчинг названий треков вконтакта с базой песен правообладателей"

(30) Если я левую запись обзову как название "песен правообладателей" что произойдет?

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

(33) еще там по звуковому отпечатку трека сравнение - но это отдельная процедура

(34) А какой смысл названия треков вместо их содержимого матчить?

вообще это nda такие подробности, но задача схожая просто

(35) Так смысл по названию то? Когда сразу по отпечаткам/содержимому надо?

(36) там много нюансов есть, например треки feat-ктото там, или ты на гитарке металлику напел в караоке, не всё матчится напрямую

(39) И?
Обзову я например транслитом вместо "Миллион алых роз" будет "Millon alyh roz" и что сделает этот "алгоритм"?

(40) ты меня вынуждаешь рассказывать подробности того что мне запрещено говорить ;)
==
вообще пример не очень правильный, можно вместо буквы о - написать английскую o, или букву ё в виде двух символов юникода если она там есть, вообще есть процедурка которая и такое определяет

(41) Точность алгоритма подозреваю хромает на обе ноги ))
Чисто для отмазки перед правообладателями и чтобы модераторам отдавать какую то урезанную выборку только и годится

(42) эффективность около 80-90% у нас была, выше было нельзя по организационным причинам, я там эту штуку с питона2 работающего в hadoop переписывал на 3 питон...в тестах до 98% поднималось...но не согласовали

(43) Меня всегда удивляет каким способом меряют эффективность ))
Взяли вручную обработанную выборку и на ней алгоритм показал 80-90% ?

А какой % вручную обработанной от всего треков в базе вк?

(17) 1. Все равно sql задействует несколько потоков процессора, а 1с на одном сидит.
2. Можно доработать, добавить т.ч. Или регистр сведений в котором разбить по словам.

(44) ну это ты уже начинаешь копать ;) понятно что нельзя добиться 100% эффективности, но то что сейчас есть вполне достаточно для работы

там еще есть такая штука что нельзя просто взять и исправить неправильно сматченные треки

вопрос все равно остается открытым. хто и зачем составил так входящий файл?
и действительно нельзя ли попытаться чтото сделать с той стороны с файлом

(0) Быстро никак. Самое быстрое - это запросом JOIN две таблицы по условию наименованиеТовара LIKE "%" + артикул + "%"

Но будет работать долго. Нужна правильная индексация наименования товара для поиска вхождения. ХЗ как в 1С это называется.

В обшем, нужно использовать полнотекстовый поиск.

Главный вопрос же не в быстро. Ну пошуршит оно подольше. Проблема в достоверности полученного результата.

(50) Достоверность можно проверить по итоговому результату. Можно найти дубли, и понять, почему там нет уникальности. А результаты без дублей считать достоверными.

Загоняешь все коды в регулярку в виде "0000000000000002|0000000000000003|0000000000000004"
пробегаешь 400 тыс строк этой регуляркой и отсеиваешь свои 100 тыс.
Потом лопатишь отсеянные 100 тыс

Оптимизация:
Делишь свою длинную регулярку на корзины по N кодов
и лопатишь 100 тыс по этим корзинкам
Потом лопатишь корзинки.

На питоне работает минут 5
На 1с может так же

ну и там найденные коды из списка удалять и сё такое. (ну ты умный. сам догадаешься)

хотя я намудрил. можно просто одним проходом всё решить

(52) (53) Пожалуй, ты единственный, мнение которого может заинтересовать меня.
Вообще не понял твою задумку.

Артикулы - это набор символов.
Строим дерево по первым символам артикулов и для каждого символа в наименовании делаем поиск по этому дереву.
И даже не дерево,а упорядоченную по порядку символов таблицу артикулов.
По ней можно дихотомиец искать.

(55) все артикулы. которые знаем(которых 100тыс) загоняем в огромную регулярку вида "(0000000000000002)|(0000000000000003)|(0000000000000004)..." и лопатим каждую строку из 400 тыс этой регуляркой. вот и вся идея


import re

x = ""
#собираем регулярку
with open("codes.txt","r") as F:
    zz = F.read()
    zz = zz.split("\n")
    zz = zz[0:-1]
    x = "(" + ")|(".join(zz)+")"

r = re.compile(x)

#лопатим файл nomen.txt. найденные выгружаем в файл out.txt. найденный код в m.group(0)
with open("out.txt","w") as OUT:
    with open("nomen.txt","r") as F:
        while True:
            s = F.readline()
            if s:
                m = r.search(s)
                if m:
                    OUT.write(m.group(0)+";"+s)
            else:
                break


(57) Мы не знаем артикулы, в условии задачи же написано, они среди мусора.

(58) Ну и тарабарщина, но смысл я понял, ничем от цикла в цикле и СтрНайти() не отличается.

Ну в принципе, и в 1С это можно сделать, главное, избегать realloc через СтрСоединить() и вывод в файл через ЗаписьТекста()

(60)цикл в цикле у тебя будет сутки работать. А так = 5 МИНУТ

(58) Регулярки - это медленно.

Сделать промежуточную таблицу, в которую загнать все наименования по несколько раз каждое, каждый раз отсекая первый символ. Типа так:
Победа
обеда
беда
еда
да
а

Индексируем таблицу. Делаем внутреннее соединение с таблицей артикулов по начальному вхождению строки.
Индексы работают если ищется совпадение с начала строки.
Ну и все, собственно. Дальше понятно. Джойн по индексам сработает достаточно быстро.

(57)(58) Это даже ее смешно
Регулярка тупо умрет

(62) регулярка как раз за тебя сделает твою беду победу
и зачем какой то гемор сочинять, если вон из 58 всё уже работает и за 5 минут всё делает
(64) попробуй сначала, а потом трынди

(63) Недорешение
Как максимальный артикул получить?
Чем отличается от (27) ?

(65) Ты думаешь регулярные выражения они как то без циклов работают?

(67) а ты думаешь цикл на машинном коде работает так же медленно как и цикл на сраном байткоде в 1С?

(68) А вот это уже другой момент
Но можно же переложить поиск-сравнение на SQL!

А если еще регулярки нормальные, то там jit и всякое такое. На питоне 5 минут. Проверено

(69) можно и на sql. можно еще на квантовом компьютере. на ассемблере тоже можно

(70) 400к артикулов пусть по 10 символов и 100к строк с наименованиям пусть по 50 символов
Посчитай скоко это в байтах

А лучше rand создать тестовый набор и проверить когда помрет ))

(72) в (58) код, который я проверил на 400к строк и 100к кодов. Работает меньше 5 минут.

вот такие наименования
<random.Random object at 0x00000177AA720E40> 0000000000000079

такие коды 0000000000000079

(73) на Unicode ?

(73) замени search() на fullmatch() :)

(66) Пока это самое правильное решение.
Так получу все артикулы, в том числе и максимальные.
От (27) отличается огромнейшим приростом быстродействия в десятки тысяч раз.

(76) это оставь для своего сервиса на go

на UTF-8 попробовал
вот такие наименования
"код, который я проверил на 400к строк и 100к кодов. Работает меньше 5 минут. <random.Random object at 0x000001915DCB2250> 0000000000000000"

2 минуты 47 сек

(77) Зачем тебе
"
беда
еда
да
а
"

когда известно, как например у меня в (27) что минимальная длина артикула 5 символов?

(78) У тебя подбирает какой артикул? Только первый?

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

Согласен что 400к и 100к это не так уж и много
Но в реальных задачах например автозапчасти там этих артикулов сотни миллионов

(79) Нигде не написано что 5 символов. Это вообще не важно, можно остановиться на "обеда", суть вообще не в этом. Это просто пример алгоритма. Параметры выбираются какие угодно.

(83) Ты не смог прочитать мой пост да?
Нигде не написано что нет смысла в коротких артикулах как и сильно длинных

Есть смысл сначала перебрать все артикулы, узнать их длины и сканом строк-наименований строить подстроки только подходящий длины

(84) Это не оптимально, мусор.

(80) все 100 тыс артикулов на 400 тыс - 2 минуты 47 сек
(81) ну на 1с будет 5 минут. надо пробовать. но мне лень. Кстати, не лень ва с sql всякими заморачиваться.... Там 10 строчек кода на 1с будет

(86) Не лень, sql приятнее чем 1С. И там тоже строчек 10 всего выходит.

(87) так надож еще sql server установить. базу создать... А на питоне чик чирик и готово.
День прошел уже :)

кстати с одинес пролет. у меня 8.3.23 нету.так бы попробовал

(88) Предлагаешь питон устанавливать? Ну нафиг. Сервер БД в любом браузере уже есть встроенный, и JS можно писать прямо в консоли, без установки сторонних программ. Даже сидя у клиента без прав админа легко осуществимо.

(90) Да его можно и не устанавливать. Можно так скачать. А на js да, то же самое будет по скорости. Серверы БД в браузерах не пробовал. Странно, что питона еще нет в браузерах. Да и 1с пора встроить уже :)

(90) выложи потом свою писанину. интересно, посмотреть

(91) Только не 1С! :) Питон можно.

По идее надо же искать начиная с самых длинных артикулов и для артикулов каждой последующей уменьшающейся длины исключать из области поиска строки в которых найдены длинные артикулы, иначе
Для строка файла
Аомраммп:МойАртикул:смпсмоа
Подойдёт и для артикула "мойартикул" И для артикула "артикул".

(92) Что именно, sql-запросы? Или создание и заполнение БД из файла?

(94) Как ты определишь что длинный артикул более правильный? Может там короткий артикул на самом деле, а остальные символы от наименования просто совпадение.

(0) ТС, скинь твой файл и выгрузку артикулов из 1С. А то тут гадание.

и нет никакой гарантии что артикул "merlo" для какого-то товара будет совершенно нормальной частью названия...
.
В итоге все будет как результат поискового запроса - похоже, но не обязательно то что нужно...
.
?

(96) от длинных к коротким хотя бы увеличит вероятность результата более похожего на правду

(99) Лучше методом исключения. Например, есть два товара:

АраратМойАртикулСамса
ПомидорМойТабакГоуранга

И два артикула: Артикул, Мой.

Под первый товар подходят оба артикула, под второй товар подходит только один артикул. Тогда принимаем что первому товару достается оставшийся артикул из двух возможных.

(100) Хотя, это не учитывает тот факт, что артикула может вообще не быть. Но хотелось бы верить что вероятность товара без артикула близка к нулю.

(97) ТС поступил как истинный одинесник. Написал цикл в циклу СтрНайти, запустил и поехал домой. Завтра всё будет готово. В кассу же всё равно завтра.

(94) Вероятно на практике все сложней
Есть еще поле производитель/поставщик или среди наименования есть еще вид номенклатуры, по которому так же надо сравнивать

Причем вид может быть сокращенным или синонимом

(103) зачем обсуждать то, чего никто не видел? Какой в этом смысл?

Будут данные от ТС, тогда и можно рассусоливать

(104) Чтобы спроектировать наиболее реальное решение
Например сразу понятно что надо не первый артикул найти а все совпадающие
Так что думаю надо использовать нечеткий поиск, чтобы не пропустить видоизмененные или частично ошибочные артикулы
Ну та "блабла", "бла-бла" и "бла бла" фактически один и тот артикул

(106) искусственный интеллект тут нужен. и сервис на go

(107) не нужен
метод N-грамм достаточно хорошо справляется с нечетким

(106) Ага, давай еще артикулы "Томат" и "помидор", "автомобиль" и "МАШИНА" считать совпадающими. Фантазия пошла в полет.

(109) это не артикулы а виды номенклатуры, о чем писал в (103)

(0) сайтики парсишь?

(111) ТС покинул ветку еще вчера. Ибо ветку замудозвонили теоретики.
Кстати я перепутал вчера. Артикулов 400 тыс оказывается, а не номенклатуры. Я чота прочитал наоборот. Так что мое решение работает теперь всего 40 сек.

import re

with open("codes.txt","r") as F:
    zz = F.read()
    zz = zz.splitlines(False)
    zz.sort()
    x = "|".join(zz)
    r = re.compile(x)

    with open("out.txt","w") as OUT:
        with open("nomen.txt","r") as IN:
            nm = IN.readlines()
            for s in nm:
                m = r.search(s)
                if m:
                    OUT.write(m.group(0)+";"+s)            



(112) это на питоне?

Сколько шума из-за одного перегона текстового файла в таблицу значений.
и одного запроса с опцией "Подобно".

(114) покажи запрос

(113) да

Питон хороший язык, если бы не его синтаксис

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

(0) В Excel + PowerQuery задача на 15 минут

(118) Напоминает Бейсик. Нет той четкости и строгости, как в Си-подобных. Не просто так же большинство ЯП выбирают такой вариант.

(120) ты точно видел бейсик?

(121) Ты знаком хоть с одним взрослым программистом, который не видел бейсик?

Деза от ChatGPT

Если вы сталкиваетесь с задачей быстрого поиска соответствия между наименованиями из файла и товарами в базе данных, то использование строковой функции `СтрНайти` в цикле может действительно быть неэффективным.

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

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

Использование многопоточной обработки или распределенных вычислений также может помочь ускорить процесс, если это применимо в вашей ситуации.

Интересно также рассмотреть возможность оптимизации базы данных, например, создание индексов на артикулах, чтобы ускорить поиск.

Не забудьте провести тестирование на небольшом объеме данных, чтобы оценить эффективность различных методов и выбрать наиболее подходящий для вашего случая.

(122) я о том, что увидеть в питоне бейсик - это какой редкий дар
(123) да вон в (112) всё делает за полминуты. А все эти Левенштейны всё равно потом бабам глазами просматривать.

(124) Я написал "Напоминает Бейсик", а не прям Бейсик-Бейсик.

(125) и чем напоминает? буквы из того же алфавита?

(126) естественно там те же буквы. Это же не 1с.

(127) в 1с тоже те же буквы.

(123) похоже на ответ от chatGPT

(128) Значит для тебя вообще все ЯП должны казаться одинаковыми, если ты так думаешь.