Форум » [x]Harbour » Scope vs Optimized Filter » Ответить

Scope vs Optimized Filter

Dima: [pre2] 1. Сейчас юзаю оптимизированные фильтры (очень удобно в SIX , ADS). Поставил фильтр и не важно на какой из индексов юзер переключится фильтр будет актуален и на нем. При добавлении записей тоже нет проблем. Считал показания Dbfilter (в общем случае) , снял фильтр и после завершения "операции" вернул фильтр на место. Речь идет только о работе с фильтрами в browse. В отчетах фильтрами я как правило не пользуюсь и выборки идут оптимально по индексам. 2. Хочется задачу перевести на Harbour , но в нем нет оптимизированых фильтров (ADS для Harbour не актуален и хочу уйти с него на LetoDB). В LetoDB так же нет оптимизированных фильтров и заменить их можно только на SCOPE или индексом CUSTOM ADDITIVE. Сustom Additive не вариант для сетевой базы да еще с большим весом самой базы. Поэтому отбросил пока этот вариант. Остался SCOPE. Работает идеально и быстрее оптимизированных фильтров. 3. Пока не представляю как оптимально и без больших доработок прикрутить SCOPE к пункту 1. Допустим юзер открыл базу в которой 5 индексов. Он может самостоятельно менять сортировку базы (переключая индексы). Понадобилось ему поставить фильтр (аля SCOPE , допустим есть и 6 индекс), он его ставит. И вот тут вопрос каков ключ должен быть у этого индекса что бы не нарушить текущую сортировку и вопрос 2: допустим SCOPE установлен, но при смене юзером сортировки , SCOPE нас покинет так как останется привязанным к 6 индексу и от фильтра аля SCOPE и следа не останется. Может есть у кого опыт перехода с фильтров в browse на scope ? [/pre2]

Ответов - 35, стр: 1 2 All

SergKis: Dima пишет:Да точно так же решается Что мы увидим (для index5) задав scope " 0"+"10"+"ABC","99"+"10"+"ABC" имея <nn>+<nn>+<nn>+name в ордере ? Поэтому я говорю - частично решает в общем случае и возможно все решает в частном Вашем. Если существует иерархия kod1->kod2->kod3 + name, НЕ участвующее в запросах для Browse, то достаточно: index name index kod1+kod2+kod3+name Если существует иерархия kod1->kod2->kod3 + name, участвующее в запросах для Browse, то: index name index kod1+name index kod1+kod2+name index kod1+kod2+kod3+name Если kod1,kod2,kod3,name независимые объекты, то надо рассматривать необходимый перечень пересечений для просмотров Browse.

Vlad04: А разве six и ads решает эту задачу ? Ads решает эту задачу через запросы. Я уже неоднократно писал , что использую с Харбор (cdx) и ADS. ADS для запросов при формирования отчетов и различных выборок. Количество параметров, по которым отбираю до десятка. Изменение таблиц через разные RDD не делаю и все нормально.

Dima: SergKis Посмотри плиз сообщение выше и мои комменты. Я прав или нет ? Dima пишет: Еще примерчик.


SergKis: Dima пишет:А вот такого плана Scope сработает верно ordscope(0," 3"+" 61") ordscope(1," 3"+" 77") Именно так !

Dima: Всем спасибо. Все понял. SergKis Теперь понятно почему столько тегов у тебя к базе ;)

SergKis: Vlad04 пишет:Ads решает эту задачу через запросы. Я уже неоднократно писал , что использую с Харбор (cdx) и ADS. ADS для запросов при формирования отчетов и различных выборок. Количество параметров, по которым отбираю до десятка. Полностью согласен. С harbour и letodb в новых прогах - тоже решаю через запросы (на memio), но что делать, если есть старые - напрямую работающие с базой Browse ? Перебирать - накладно.

Pasha: Vlad04 пишет: Ads решает эту задачу через запросы. Я уже неоднократно писал , что использую с Харбор (cdx) и ADS. ADS для запросов при формирования отчетов и различных выборок. Количество параметров, по которым отбираю до десятка. Запрос это не панацея. Использование запроса приводит только к уменьшению сетевого трафика, и не более. Сам запрос может быть как оптимальным, так не оптимальным. Если для выполнения запроса находится соответствующий индекс (план), то выборка будет ограниченной, т.е оптимальной. Если такого индекса нет, то для выборки нужен цикл по всей таблице, т.е. полный перебор, что не есть хорошее решение. Запросы могут быть и частично оптимальными. Часто при нынешних высокопроизводительных компьютерах и не почувствуешь, оптимален запрос или нет. Поэтому желательно сначала научиться строить такие запросы ручками, т.е. определить необходимые индексы, указывать, какой из них будет управляющим. Потом это будет уже на автомате.

Vlad04: Кто бы спорил . Я и SCOPE применяю и временные индексы. Что и как применять зависит от многих условий ... Хорошо , что есть выбор. Жаль, что в Харбор встроенного SQL нет.

Pasha: Dima пишет: index on str(kmcod,6)+str(codgr,6) to klient А вот так не работает как ожидалось ordscope(0," 0"+" 61") ordscope(1," 3"+" 61") Чтобы при таком индексе работало, надо задать: ordscope(0," 0") ordscope(1," 3") set filter to codor=61 Это будет частично оптимизированный фильтр. Чтобы сделать полностью оптимизированный фильтр, нужен индекс с полями наоборот: index on str(codgr,6)+str(kmcod,6) to klient2 и фильтр scope: ordscope(0,str(61,6)+str(0,6)) ordscope(1,str(61,6)+str(3,6)) Надо определиться, как часто понадобится такая выборка, прежде чем создавать дополнительный тэг

Dima: Pasha пишет: Надо определиться, как часто понадобится такая выборка, прежде чем создавать дополнительный тэг Да я вот тоже задумался , но все равно что то делать нужно , так как с Clipper и ADS хочется уйти. Решил начать с фильтров. А задача не кислая , 4.5 метра исходников.

Pasha: Если оставить прежний набор индексов, то надо только правильно выставлять управляющий индекс в каждый момент времени. Работать будет не хуже, чем при прежнем алгоритме. Новые индексы (тэги) надо добавлять, если хочется что-то улучшить. Но это необязательно. Лучшее - враг хорошего. Это я по своему опыту сужу.

Dima: Pasha пишет: Если оставить прежний набор индексов, то надо только правильно выставлять управляющий индекс в каждый момент времени. Работать будет не хуже, чем при прежнем алгоритме. Да дружище это я понял уже и перевариваю.....

ММК: AlexMyr пишет: все записи по конкретному таб ном + по заданному году + по заданному месяцу+по заданному виду А если год >2010 + 3>месяц<7 то как ?

Dima: ММК пишет: А если год >2010 + 3>месяц<7 то как ? С помощью только Scope ни как. А вот если выбрать конкретный год и месяца с 3 по 7 то можно ;)

SergKis: AlexMyr пишет:все записи по конкретному таб ном + по заданному году + по заданному месяцу+по заданному виду В задаче, правильнее начинать с тега, собранного по времени: DtoS(FielddDate)+tnom+..., т.к. запросы, как правило, начинаются с периода. В данном случае такой тег с датой дополнительно иметь не помешает.



полная версия страницы