фильтры

Гость

Здравствуйте.

c55, ШВС

Броуз по файлу, условный выриант, ключ из трех полей (все поля long).

1. Задаю ограничение на первый элемент ключа по указанному значению равному 1 (причем в таблице записи в основном со значением 0 в этом поле) - работает все замечательно.

2. Прописываю фильтр Поле 2 = Переменная. В результате этого имею жуткие тормоза.

--
Эмберге! Арсений mailto:arseniy-at-home@yandex.ru

Гость

Это вполне естественно, так как для того, чтобы сработал фильтр, нужно проверить каждую дату.
Можно фильтр сделать не так. Есть такая рутинка BRW1::Validaterecord, условие фильтра можно задать в ней:

Код: Выделить всё

if <field_2> not = <variable_2> then exit.

Если фильтр очень сложный, можно поставить после него Yield, чтобы дать операционке знать, что твоя прога дышит, а не тормозит, фильтруя записи.
На мой взгляд, это срабатывает быстрее.

--
Best regards,
Anatoly mailto:warthog@belarusbank.minsk.by

Гость

Не понятно - фильтр по полю 2 работает с фильтром по полю 1 или первый пункт никак не связан со вторым, т.е. работает только фильтр по полю 2?
Если есть фильтр только по полю 2, то - все закономерно!
Ключ - это дерево, каждый из уровней которого - ключевое поле.
Быстро можно просмотреть ТОЛЬКО целиком весь первый уровень (т.е. фильтр только по первому полю) или очередной уровень какой-либо ОДНОЙ ветви.

Код: Выделить всё

01: 1Поле
02:   2Поле
03:   2Поле
04:     3Поле
05:     3Поле
06:     3Поле
07:   2Поле
08:     3Поле
09: 1Поле
10: 1Поле
11:   2Поле

- Если установлен фильтр по Полю1, то быстро можно пробежаться по верхним веткам 01-09-10.
- Если установлено ФИКСИРОВАННОЕ значение Поля1 и есть доп. фильтр по Полю2, то опять-же, можно быстро просмотреть все записи второго уровня ветки 01: 02-03-07
- Если установлено ФИКСИРОВАННОЕ значение для Поля1 и Поля2 и есть доп. фильтр по Полю3, то опять-же, получаем быструю выборку: 04-05-06

Из схемы видно, что если есть фильтр ТОЛЬКО по Полю2, то для выборки необходимо "проваливаться" в КАЖДУЮ ветку первого уровня и в КАЖДОЙ производить выборку по Полю2.
Т.е., при РУЧНОМ обходе с оптимизированным алгоритмом надо пройтись как минимум по 01-09-10 и, дополнительно, по некоторым записям второго уровня ветки 01 и захватить запись 11.
Я НЕ УВЕРЕН, что VIEW использует такой оптимизированный алгоритм.
А с обычным алгоритмом прийдется обойти ВСЕ записи таблицы, включая и ненужные, по условиям фильтра, записи третьего уровня!

Если-же фильтр у тебя задан и для поля1 и для поля2 одновременно и, как ты написал, задано ФИКСИРОВАННОЕ значение поля1, то надо смотреть на сам фильтр - возможно используются обороты, которые труднопонимаемы для парсера VIEW и не могут быть преобразованы в быстрый проход. Опять-же - какой тип у Поля2?
Для строковых полей, к примеру, очень часто помогает задание в фильтре UPPER(Поле2). Естественно, только для регистронечувствительной выборки. Хотя, честно говоря, еще ни разу не приходилось это использовать - нормально работает и так.

Вообщем, распиши свой вопрос более подробно.

Удачи!

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Написал: ClaList(2)

Гость

Спасибо за столь развернутый ответ. Проблема была не в фильтрах, проблема была в порядке условных вариантов - как всегда подводит собственная невнимательность.
Но есть еще один вопросик: вот для такого файла

Код: Выделить всё

my_file file
my_key key(f1,f2)
record record
f1       long
f2       long
   end
  end

что будет работать быстрее

Код: Выделить всё

f1 = value1
f2 = value2
set(my_key,my_key)
loop
 next(my_file)
 if errorcode() or (f1<>value1) or (f2<>value2) then break .
 .....
end

или если файл сунуть во view и {prop:filter} = '(f1 = value1) and (f2 = value2)'
?

Вопрос возникает потому что browse все равно работает не очень быстро, особенно по сети. Кстати, если более подробно, то в условном варианте вот что написано:

Используемый ключ: my_key
Фильтр переменная: f2 = value2
Ограничение на: f1
Тип ограничения: заданное значение
Требуемое значение: переменная long

Может быть здесь собака порылась?

--
Эмберге! Арсений mailto:arseniy-at-home@yandex.ru
Написал: ClaList(2)

Гость

Вообще-то, быстрее работать будет первый вариант:
SET на первую запись последовательности - минимум времени.
А дальше идет обычное чтение по ключу всех записей подряд до вылета из цикла. Другое дело, что для бровза приведенная выборка - "плевое дело" и лишние милисекунды, затраченные VIEW, просто будут не заметны.

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

А что значит - "все равно работает не очень быстро"?
Где именно замедление:
- на этапе открытия бровза
- при заполнении первой/очередной страницы
- при обычной построчной прокрутке бровза

И, кстати, или я не обратил внимание, или ты забыл указать версию и вид шаблонов.
Дело в том, что в ABC (и, вероятно, в последней версии офоициальных Legacy-шаблонов от SV) есть две идеологии работы с бровзом - страничная и полная загрузка.
При второй во внутреннюю очередь бровза при его открытии загружаются ВСЕ записи, удовлетворяющие фильтру.
Естественно, что при большом кол-ве записей в выборке это может значительно замедлить первоначальное открытие бровза.
При твоих условиях самой идеальной является страничная идеология - VIEW быстро находит первую запись нужной последовательности и быстро заполняет первую страницу.
Да и дальнейшая работа должна идти без видимых тормозов.

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

Потому, что приведенный тобой фильтр - простейший вариант выборки и VIEW с ним должен справлятся вообще без проблем.

=============================
С уважением, Олег А. Руденко
Написал: ClaList(2)