forum.clarionlife.net

Как большой спец по подобной проблеме делюсь своим бесценным опытом:

Поиск по Match/Instring gпо файлу на диске заметно медленнее, чем по IMDD или Queue
Сам поиск производится достаточно быстро (250т. записей, по, максимум, 50к на запись), что позволяет реализовывать, фактически, фильтр в Browse в режиме онлине, т.е. клиент набирает в поле, а в списке сразу отражается

А вот процесс ЗАНЕСЕНИЯ в память с диска далеко не тривиален. Любое наличие ключей в IMDD или использование Queue с сортировкой тормозит процесс очень знатно.

Губин Игорь писал(а): Любое наличие ключей в IMDD или использование Queue с сортировкой тормозит процесс очень знатно.

Просто добавляем записи Append() и перестраиваем потом ключи Build() или Sort() для QUEUE.

Губин Игорь писал(а): Поиск по Match/Instring по файлу на диске заметно медленнее, чем по IMDD или Queue

А вот за это наблюдение отдельное спасибо.

Игорь Столяров писал(а): Просто добавляем записи Append() и перестраиваем потом ключи Build() или Sort() для QUEUE.

ЩаЗЗЗЗЗЗ. Не смотрите на мою подпись
Не всё так просто. Дело в том, что выигрыш Append + Build для IMDD или Sort для Queue, при правильном занесении данных в память, по сравнению с Add не то, чтобы минимален, а то и занимает больше времени.

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

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

Игорь Столяров писал(а): А вот за это наблюдение отдельное спасибо.

Всегда пожалуйста. Когда я сделал такое - клиенты запищали в экстазе.

Учти, что под "медленнее" я подразумевал не просто поиск по готовым файлам, а комплекс (подкачка в память+поиск). И выигрыш есть даже для однократного поиска.

Привет.
В ШВС есть фильтр по очереди. Там вначале идентификаторы нужных записей отбираются в кьюшку, а затем уже по списку идентификаторов формируется строка фильтра. Проблема медленной работы броуза в постоянном пересчитывании записей, а с фиксированным списком работает шустро. Пробовал как раз на 100+ тыс записей (справочник товаров), причем поиск не просто по фрагменту, а по набору фрагментов (то есть для каждой записи проверяется несколько instring). Единственный момент, есть ограничение по количеству отобранных записей, поэтому приходится делать их постраничное переключение, если много. По сети не пробовал, у нас таких клиентов, можно сказать, нет... Пользователям нравится.

Игорь,
кажется мы примерно всё то же самое уже обсуждали вот здесь http://forum.clarionlife.net/phpbb/viewtopic.php?t=3301 полтора года назад.

Shur писал(а): Игорь,
кажется мы примерно всё то же самое уже обсуждали вот здесь http://forum.clarionlife.net/phpbb/viewtopic.php?t=3301 полтора года назад.

Вечные проблемы... Любовь, смерть, ускорение поиска по записям...

Да, я пару лет назад проводил аналогичное исследование, а вот в начале года повторил его "на новом уровне", перебирая уже все возможные варианты.
Кстати, всплыло и много интересного по работе клариона с файлами в сети, но я это уже, тоже, писал

Игорь Столяров писал(а): Все работает. Но мееееедленно. Особенно в сети. Может быть есть идеи по альтернативному варианту контекстного поиска в Browse ?Заранее спасибо за идею.

Про медленно по сети. Напишите серверное приложение а-ля сервис, которое для снижения трафика по сети было бы запущено на сервере данных. В своих внутренностях оно [приложение] могло бы иметь QUEUE, IMDD или таблицу поиска (см. ссылку 1 постом выше) -- как захотите. На входе бы получало строку поиска, на выходе список ID подходящих записей. Оставалось бы вывести в броуз записи по выданному списку.

Shur писал(а):Оставалось бы вывести в броуз записи по выданному списку.

Зачем же так напрягаться ? Существует SV IP Driver, который в принципе описанный функционал и реализует ...

Игорь Столяров писал(а):

Shur писал(а):Оставалось бы вывести в броуз записи по выданному списку.

Зачем же так напрягаться ? Существует SV IP Driver, который в принципе описанный функционал и реализует ...

Ну ещё лучше.

Shur писал(а): Ну ещё лучше.

Это да, если бы он только был доступен, то и проблемы не было.

Shur писал(а):

Игорь Столяров писал(а):

Shur писал(а):Оставалось бы вывести в броуз записи по выданному списку.

Зачем же так напрягаться ? Существует SV IP Driver, который в принципе описанный функционал и реализует ...

Ну ещё лучше.

Да, только не годится для случая, когда любое изменение в системе заказчика должно быть сведено к минимуму, в крайнем случае, легко производиться и администрироваться, желательно силами "удалённой" секретарши

Полтора года назад было требование "SQL не предлагать". Может сейчас всё-таки предлагать? Разработчики SQL всё-таки делают что-то для этого дела.

kreator писал(а): Может сейчас всё-таки предлагать?

SQL занимаемся, и конкретно Firebird. Купил на OZON толстую книжку, читаю. Но это так сказать перспектива.
А есть хлеб насущный, большие проекты, которые нужно поддерживать в том виде как они есть ...

Вообще проблема не так проста. Если копнуть глубже, то никакой instring и даже like не годится. MS, например, предлагает - https://technet.microsoft.com/ru-ru/lib ... .105).aspx.

Должно быть так https://technet.microsoft.com/ru-ru/lib ... .105).aspx