Записки оптимизатора 1С (часть 2). Полнотекстовый индекс или как быстро искать по подстроке

[Skykharkov]

Когда-то делал быстрый поиск по корпусу русского языка. Решение свелось к разделению базы по таблицам, по начальным символам. "А*", "AA*" ну и так далее, вы поняли. При довольно большом объеме скорости хватало.

[Nikeware]

Sphinx Search вам в помощь.

[nick-for-habr]

А как на ваше творчество смотрит фирма 1С, ибо оно (творчество) есть грубейшее нарушение лицензии? Шутка конечно, но...

[Ghostcar]

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

[koloskovv]

Никаких сложностей нет. Обновление конфигурации на стороне 1С не затрагивает новую таблицу и её индексы.

[Ghostcar]

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

[koloskovv]

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

[koloskovv]

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

[koloskovv]

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

[belch84]

Когда-то делал специальный вариант поиска по вхождению, он предназначался для частного случая — поиска клиента по его названию (в какой-то момент просто поиск по вхождению стал работать слишком долго). Остановился на таком варианте — ночью автоматичеси запускалось задание, в котором все названия клиентов разбивались на отдельные слова и строилась (точнее, дополнялась новыми словами) отдельная таблица, содержащая слова и указатели на названия клиентов, содержащие конкретное слово. В интерфейсе для собственно поиска был предусмотрен простейший синтаксис — если было задано просто слово («Поликлини» — по указателю отыскивались клиенты, в назании которых было слово, начинающееся на «Поликлини»), если слово предварялось "*" — выполнялся обычный поиск по вхождению. Можно было задать несколько слов для поиска, при этом для ускорения нужно было, чтобы хотя бы одно из слов не предварялось "*". Поскольку указатель перестаивался ночью, возможны были случаи, когда поиск не находил клиента, название которого изменялось сегодня, тогда приходилось применять обычнй поиск по вхождению. В целом все это работало (кстати, и сейчас работает). Не SQL и не 1С

Пример задания условий поиска

[koloskovv]

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

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