gifts2017

Полнотекстовый поиск по значениям реквизитов

Опубликовал Vladimir Kulikov (vladim-kul) в раздел Администрирование - Чистка базы

Обработка расширяет возможности Полнотекстового поиска, позволяя искать похожие элементы в ЛЮБЫХ Справочниках ЛЮБОЙ конфигурации по проценту совпадения значений выбранных реквизитов. Работает в Обычном и Управляемом режиме!!

Стандартный полнотекстовый поиск имеет один недостаток - не позволяет искать похожие значения до уровней реквизитов.
Предлагаемая обработка значительно расширяет функционал Нечеткого поиска.
В частности, позволяет осуществить поиск ПОХОЖИХ позиций в любом Справочнике ЛЮБОЙ конфигурации 1С по проценту совпадения значений ВЫБРАННЫХ реквизитов.
Например, "Наименование на 80% похоже на РОГА И КОПЫТА, и ОКОПФ = ООО".
Учитывает транслит. Игнорирует Регистр.

Поиск может осуществляться для тех Реквизитов, у которых разрешен Полнотекст и включена Индексация на уровне Конфигурации.

Работает в Обычном и Управляемом режимах!

ПОЛНОСТЬЮ ОТКРЫТЫЙ КОД!!

PS У Вас в базе должен быть включен Полнотекстовый поиск. Если не знаете как - обращайтесь, пришлю внешнюю обработочку с одной кнопкой Cool

 

Скачать файлы

Наименование Файл Версия Размер
Полнотекстовый поиск по реквизитам 95
.zip 355,33Kb
25.12.13
95
.zip 4.0 355,33Kb Скачать

См. также

Contragent+ 5.0 от 2 500
Подписаться Добавить вознаграждение
Комментарии
1. Allexey (alex_4x) 25.12.13 22:38
Я полнотекстовый поиск по максимуму отключаю, так как он лишние тормоза создает, а реально не применяется. Всё что надо искать - названия фирм и товаров, а не строки произведений и легко обходится запросами типа
like %блаблабла%.
cool.vlad4; +1 Ответить 1
2. Vladimir Kulikov (vladim-kul) 25.12.13 22:48
(1) alex_4x,
ну вот Вам и пример реального применения Полнотекста.
Протестировано на базе 50+К Номенклатуры. 10 Секунд - таково время завершения поиска этой обработкой.
При наличии в базе около 100 Пользователей в это время.
Так что у вас там явно траблы с железом или оптимальностью в критических участках программного кода)
Ну, или база файловая... Но и тут можно придумать выход =)
3. Алексей 1 (AlX0id) 26.12.13 00:13
(2) vladim-kul, так он тормоза создает не во время поиска, а во время индексации, извлечения текстов и т.п. )
На самом деле все условно, конечно.. Вряд ли существенно заметны "тормоза" от индексации при неспешном вводе пользователям документов.. Не в каждой же конторе пользователи, как бешеные, вбахивают по 100 позиций номенклатуры в секунду..
4. Яков Коган (Yashazz) 26.12.13 13:26
Не советую использовать полнотекстовый поиск от 1С, если на то нет совсем уж критической необходимости, да и то - опционально, как "бантик". С индексацией действительно всё плохо и со стороны 1С не особо оптимизировано. Элементарный пример - мы НЕ можем управлять индексацией, индекс обновляется весь целиком или никак, а если мне сегодня и щас надо переиндексировать по одному справочнику из трёх, то фигушки. И уж частью функционала такой поиск точно делать нельзя.

Если что надо, проще самому заняться - сделать поисковые реквизиты, регистры итд, идти по ним LIKE'ом или RegExp задействовать, или возможности ПостроительDOM, или ещё как. Быстрее бывает, и управляемее.
cool.vlad4; +1 Ответить
5. Ийон Тихий (cool.vlad4) 26.12.13 14:31
(2) vladim-kul, 10 секунд - это очень много (умолчу про то, что яндекс например ищет среди миллиона, миллиарда всякой информации за время раз в 10 меньшее;) ) . Вот вы представьте, что в поисковике интернета, которым вы пользуетесь, время между запросами было 10 секунд? стали бы вы им пользоваться? вот и обычные пользователи вас не поймут, им все равно полнотекстовый поиск это, внешняя компонента или что. я как-то тестировал поиск с помощью разных способов. и остановился на способе, который здесь все и упоминают - like, + ВК strmatch. Еще можно отметить, что иногда пользователям не нужен нечеткий поиск или поиск по части слова, они просто скопировали наименование откуда-то и хотят найти точно данный объект. Это тоже надо учитывать.
6. Ийон Тихий (cool.vlad4) 26.12.13 14:34
(3) AlX0id, мне он не понравился еще и потому, что возможна гипотетическая ситуация, когда индекс не успел обновиться, а пользователь уже хочет что-то найти. если учесть многопользовательскую работу, которая может быть даже между пользователями, находящихся в разных городах (ну мало ли), то возможны нехорошие ситуации. т.е. я бы не стал применять такой поиск как основной.
7. Vladimir Kulikov (vladim-kul) 26.12.13 14:37
(5) cool.vlad4, вообще, назначение обработины - находить потенциальные дубли. Например, перед вводом нового элемента справочника. В целом - я никого не принуждаю использовать данный функционал :)
insurgut; +1 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа