Если очистить индекс полнотекстового поиска и не запускать его обновление, то в пользовательской части никаких видимых изменений - полнотекстовый поиск вроде как работает. Как это у него так получается?
Проверял в том числе на большой базе с индексом в 15 гиг и физическим удалением файлов индекса.
---
проверял на стандартном поле поиска динамического списка? Там все хитро устроено.
вот тут подробное описание работы:
https://infostart.ru/1c/articles/1056842/
---
проверял на стандартном поле поиска динамического списка? Там все хитро устроено.
вот тут подробное описание работы:
https://infostart.ru/1c/articles/1056842/
---
Если полнотекстовый поиск прекрасно работает без создания полнотекстового индекса, может его и создавать не надо? :)
---
Полнотекстовый поиск ускоряет выполнение запросов. Вы проверяли скорость выполнения сложных отчетов, вроде остатков номенклатуры или расчетной ведомости организации?
---
Полнотекстовый поиск ускоряет выполнение запросов.
С точки зрения моего понимания того, как устроен и работает полнотекстовый поиск - это полная ересь. СУБД вообще ничего не знает про полнотекстовый поиск 1С и не способна принимать его во внимание при построении планов выполнения запросов.
Если вы это не сами придумали - то хотелось бы пруфов.
ЗЫ. Хотя мое понимание того как он устроен и работает ограничивается знанием, что он складируется в файлики на сервере кластера приложений. Как я понимаю, при полнотекстовом поиске 1С по данным из этих файлов определяет список ссылок и применяет их в качестве фильтра.
---
Надо будет выбрать время и поэкспериментировать на копии базы. Если окажется, что при отсутствии индекса полнотекстового поиска поиск в динамических списках работает в некоем "режиме эмуляции" без особых побочных эффектов и с приемлемой производительностью - то может нафиг этот полнотекстовый индекс? Одни проблемы от него.
---
Огромное спасибо за ссылку! Именно то, что я искал. То есть платформа в самом деле способна "эмулировать на запросах" работу индекса полнотекстового поиска. Гоняю на копии рабочей базы. Пока производительность устраивает даже на самых заковыристых вариантах и больших таблицах. Если все будет ОК - отключу его нафиг и на рабочей базе.
---
многие так и делают. ППД нужен для не системного поиска. Скажем поиск по всей конфигурации (на форме самого приложения). Но обычно на него забивают.
---
Единственное, до конца неясен триггер, по которому платформа начинает искать через запросы, а не через индекс ППД.
Для ППД месячной актуальности, например, какой платформа выберет вариант?
---
тут больше методом тыка.
Но за основу взять это:

Для динамических списков с указанной основной таблицей используется полнотекстовый поиск по основной таблице. К результатам полнотекстового поиска будут добавлены все непроиндексированные ссылки из основной таблицы.
Но не будет найдены текстовые внутренние совпадения, если их нет в ППД. Как я понял ПОДОБНО %ТекстПоиска% не отработает через запрос.
---
Вот еще продолжение от того же автора: https://infostart.ru/1c/articles/1278933/
Все-таки нашел варианты, когда не зная особенностей работы поиска пользователь способен через общий поиск получить малоюзабельное поведение системы из-за слишком тяжелых запросов. Склоняюсь к тому, чтобы оставить индекс ППД, но провести его полную ревизию. Оставив индексацию только для тех полей, которые будут оптимизировать поиск по таким "тяжелым" вариантам.
---
это если терпения хватит все править :)
---
Ну и еще (то что и сам раньше заметил и в статьях нашел подтверждение). Если просто отключить регламенты, но сам ППД оставить включенным - то платформа будет искать запросами, но при этом продолжать фиксировать изменения для ППД в файликах. Некритично, но непорядочек :) То есть если отключать - то лучше отключать полностью.
(12) Один раз можно и напрячься. Плюс в статье предложен вариант глобального отключения - выгрузить конфу в файлики и общей заменой. Останется только пройтись и включить где нужно.