Глобальный поиск, не ищет штрихкоды

[glibs]

Я имел в виду поле "Индекс по тексту".

Я так понимаю вы запустили индексацию в фоновом режиме и не останавливали. А как давно? Или пробовали останавливать? И сколько у вас записей в таблице с номенклатурой?

Вообще индексация работает небыстро. Алгоритм перебирает все записи в таблице последовательно, анализирует указанные текстовые поля (разбирает текст на слова по определенному алгоритму), для каждого из найденных слов вставляет минимум одну запись в таблицу + для каждой записи в индексируемой таблице сохраняется по одной записи для каждого слова в названии таблицы + еще одна строчка с указанием на запись + если находится новое слово, то еще одна запись вставляется.

Если у вас есть представление насколько медленные Аксаптовские функции парсинга текстовых переменных, и насколько быстро в принципе может происходить вставка данных в реляционной СУБД, то можете себе это представить. У меня полная реиндексация порядка 25 тысяч записей в двух таблицах занимала около 20 часов. Правда, алгоритм индексации был насильственно принужден индексировать Memo-поля со средней длинной текста около 500 байт, кажется.

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

И еще. В настройке таблиц на первой закладке есть поле типа "Инкрементный" (я русский интерфейс не помню, извините). Так вот если у вас там не стоит галочка — то это плохо. Механизм индексации в таком случае очень неэффективен. Он постоянно переиндексирует все данные. Если же галка стоит, то он переиндексирует только измененные с момента последней индексации записи. При первой индексации это не существенно, но если вы остановите агента и запустите снова, то эффект будет принципиально разным.

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

Короче возможности движка ограничены. Он не всемогуч. И это не Яндекс.

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

[dn]

Цитата:

Сообщение от glibs

Правда, алгоритм индексации был насильственно принужден индексировать Memo-поля со средней длинной текста около 500 байт, кажется

Т.е. этот механизм можно использовать для поиска по мемо-полям?

[AndyD]

Цитата:

Сообщение от glibs

Если у вас есть представление насколько медленные Аксаптовские функции парсинга текстовых переменных, и насколько быстро в принципе может происходить вставка данных в реляционной СУБД, то можете себе это представить.

По-моему, здесь как раз тот случай, когда на сколько бы ни был тормозным x++, но соединение с базой - еще тормознутее

Помимо непосредственно операций вставки в коде еще много поисковых запросов и запросов на удаление.

К примеру, удаление из таблицы sysSearchPath

    delete_from sysSearchPath
        where sysSearchPath.Design     == design     &&
              sysSearchPath.LanguageId == languageId &&
              sysSearchPath.URL        == URL;

Вроде бы, выглядит все хорошо - один запрос, индексы используются.
Но вот только на таблице висит DeleteAction Cascade для sysSearchRef. И тут же дополнительно появляется неявный запрос на выборку из sysSearchPath с последующим удалением из sysSearchRef.

Или запрос

sysSearchName = SysSearchName::findRecId(word, design, languageId);

который вызывается для каждого слова, входящего в индексируемые поля
Опять-же - поиск по индексу, на таблице включено кэширование (Found).
Но если количество слов окажется больше размера кэша (2000 записей для сервера, чего при построении индекса по большим таблицам слишком мало), то запросы уже будут идти не в кэш, а на сиквел. И есть подозрение, что при этом кэш начнет активно обновляться.

В общем, регулярные выражения в Аксапте конечно неторопливы, но основные тормоза, в данном случае, не в них

Что бы убедиться, что проблема действительно в количестве обращений к базе данных, переписал код на использование класса System.Text.RegularExpressions.Regex. По тестам чистого разделения строки на слова производительность этого класса раз в 20 была выше на моей системе, чем TextBuffer, плюс еще сделал кое-какую оптимизацию кода.
Но на итоговую скорость выполнения это сказалось крайне слабо - время выполнения улучшилось максимум процентов на 10

Цитата:

Сообщение от glibs

И еще. В настройке таблиц на первой закладке есть поле типа "Инкрементный" (я русский интерфейс не помню, извините). Так вот если у вас там не стоит галочка — то это плохо. Механизм индексации в таком случае очень неэффективен. Он постоянно переиндексирует все данные. Если же галка стоит, то он переиндексирует только измененные с момента последней индексации записи. При первой индексации это не существенно, но если вы остановите агента и запустите снова, то эффект будет принципиально разным.

Галка показывает, есть на индексируемой таблице поле ModifiedDateTime или нет. Это дисплейный метод и влиять на него мы может только включением/выключением ModifiedDateTime на таблице
(Просто уточняю на всякий случай)