В своё время написал программу для нечеткого сравнения строк FuzzyStringComparison. Теперь у меня возникла необходимость во внешней Native-компоненте с таким же функционалом.
32х и 64х-разрядные компоненты входят как макет FuzzyStringComparisonNative в прилагаемую к статье обработку "Проверка библиотеки FuzzyStringComparison Native".
Содержимое ZIP-архива из макета обработки представлено на скриншоте:
Компонента проводит транслитерацию с последующей адаптацией фонетического алгоритма для русского языка. И далее проводится сравнение в соответствии с установленными флагами.
Более подробно теоретическую часть, заложенную в работу компоненты можно прочитать здесь.
Компонента проста в работе и имеет три функции и два свойства:
1. функция ПодготовитьИсточник(SRS)
В качестве реквизита SRS надо передать текст с любым количеством строк, вида:
Код или номер строки или любой уникальный номер|Наименование товара|
которые разделены между собой символом перевод строки, н-р:
20835|A-Thermic носки Alpinist p.35-38|
20836|A-Thermic носки Alpinist p.39-42|
20837|A-Thermic носки Alpinist p.43-46|
Наличие символов "|" обязательно, т.к. по ним идет парсинг строк в компоненте.
2. функция ПодготовитьПриемник(DST)
По аналогии с 1-ой функцией, в качестве реквизита DST надо передать текст с любым количеством строк, вида:
Код или номер строки или любой уникальный номер|Наименование товара|
которые разделены между собой символом перевод строки, н-р:
19237|A-Thermic носки Running p.35-38|
19235|A-Thermic носки Running p.39-42|
19236|A-Thermic носки Running p.43-46|
3. Функция Сравнить()
Первые две функции можно вызывать в любой последовательности. Но функция Сравнить вызывается строго после первых двух, т.к. сравнивает подготовленные ими данные. Как видно функция Сравнить без параметров.
На выходе функция Сравнить возвращает текст вида:
Код_Приемник|Наименование_Приемник|Код_Источник;Расстояние_Левенштейна|, например:
26683|ящик A-Elita Sputnik|31403;0|16115;5|24613;6|02463;7|08040;11|21620;11|02243;12|09474;12|10807;12|15352;12|
13708|ящик A-Elita малый Sport|16115;5|02463;9|31403;10|24613;10|06966;13|03118;13|07200;13|06204;14|00447;14|19550;14| 21436|
ящик A-Elita малый SportBeg яркий|16115;13|31403;14|24613;15|02463;17|09744;19|27177;19|21620;19|04494;20|02727;20|14652;20|
Коды из базы-источника выстраиваются по возрастанию расстояния Левенштейна (0 - полное соответствие).
Если используется альтернативный алгоритм, тогда коды выстраиваются по убыванию (100 - полное соответствие).
Количество соответствий в настоящей версии компоненты 24 штуки, что более чем достаточно.
4. Булевские свойства "АлгоритмЛевенштейна" и "АлгоритмМетафон"
Флаги АлгоритмЛевенштейна и АлгоритмМетафон, при желании, можно менять перед вызовом функции Сравнить(). По умолчанию во внешней компоненте:
АлгоритмЛевенштейна=Истина
АлгоритмМетафон=Истина
Ещё раз напомню, что теоретическую часть, заложенную в работу компоненты, можно прочитать здесь.
Описание обработки "Проверка библиотеки FuzzyStringComparison Native"
Обработка без правок должна работать в любой конфигурации на УФ, имеющей справочник Номенклатура.
В обработке есть четыре текстовых многострочных поля. При открытии поля SRS (источник) и DST (приемник) заполнены 19-ю одинаковыми строками. При желании можно посмотреть как меняется строка Результат при изменении флагов "Использовать алгоритм Левенштейна" и "Использовать алгоритм Metaphone".
При нажатии кнопки "Заполнить источник товарами из запроса" поле "SRS" заполняется данными из справочника Номенклатуры. В запросе обработки использовалась функция Строка(), которая работает с релиза платформы 1С 8.3.20.1549.
Нижняя строка отражает статистику времени работы при установке тех или иных флагов. Как видно из 1-ого скриншота, самое быстрое время работы при двух установленных флагах.
SRS (137 552) DST (19) Результат (19) 1 309 сек Время начала 20.05.2024 14:29:02 (АлгоритмЛевенштейна=Нет; АлгоритмMetaphone=Нет)
SRS (137 552) DST (19) Результат (19) 294 сек Время начала 20.05.2024 14:23:14 (АлгоритмЛевенштейна=Нет; АлгоритмMetaphone=Да)
SRS (137 552) DST (19) Результат (19) 45 сек Время начала 20.05.2024 14:22:08 (АлгоритмЛевенштейна=Да; АлгоритмMetaphone=Нет)
SRS (137 552) DST (19) Результат (19) 35 сек Время начала 20.05.2024 14:20:37 (АлгоритмЛевенштейна=Да; АлгоритмMetaphone=Да)
"Подводные камни" с которыми столкнулся при написании обработки:
1. Запрос на выборку 137552 товаров отрабатывал быстро, но последующая его укладка в строку через цикл работала очень долго, что сильно напрягало. Поэтому придумал алгоритм по быстрой укладке массива со столбцом из таблицы значений в нужную мне строку, через функцию ЗначениеВСтрокуВнутр(). Функция СтрСоединить() значительно улучшила производительность свертки столбца таблицы значений в строку.
2. Установку компоненты из ZIP-архива (макета обработки FuzzyStringComparisonNative) при каждом запуске выполнять не обязательно! Но если уже установлена старая версия компоненты, а надо использовать новую, тогда без установки не получится.
При подключении компоненты из ZIP-архива (макета обработки FuzzyStringComparisonNative) используется ранее установленная компонента. Компоненты устанавливаются в профиле пользователя "%AppData%\Roaming\1C\1cv8\ExtCompT\"
В обработке реализованы три механизма подключения внешней Native компоненты:
1. 1-ый вариант: подключение ВК из файла. Этот способ работает всегда, т.к. идет обращение к компоненте напрямую, а не через сохраненную копию в профиле пользователя.
2. 2-ой вариант: подключение ВК из общего макета. Этот способ работает только если не надо запускать новую версию компоненты, т.к. вначале происходит подключение к компоненте, а если подключение не прошло тогда компонента устанавливается. При подключении компоненты из ZIP-архива используется ранее установленная компонента. Компоненты устанавливаются в профиле пользователя "%AppData%\Roaming\1C\1cv8\ExtCompT\"
3. 3-ий вариант: подключение ВК из макета обработки. Проблемы аналогичные варианту 2, но в этой обработке устанавливаю компоненту каждый раз при запуске обработки. В обработке использую по умолчанию этот вариант.
