Форум » [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

AlexMyr: Dima пишет: опустим юзер открыл базу в которой 5 индексов. Он может самостоятельно менять сортировку базы (переключая индексы). Понадобилось ему поставить фильтр (аля SCOPE , допустим есть и 6 индекс), он его ставит. И вот тут вопрос каков ключ должен быть у этого индекса что бы не нарушить текущую сортировку Дима, Вы бы показали кусок кода с фильтром, легче было бы понять как scope прикрутить.

SergKis: Dima пишет:Пока не представляю как оптимально и без больших доработок прикрутить SCOPE к пункту 1 В Clipper с SIX имею в проге к dbf 48 индексов именно для Scope, Filter использовал только как дополнение к Scope в формах. Работает более 10 лет без проблем. Думаю вряд ли CDX Harbour менее надежен.

Dima: SergKis пишет: В Clipper с SIX имею в проге к dbf 48 индексов именно для Scope Жесть. Они у тебя как теги или каждый индекс в отдельном файле ? Если в отдельном то там ограничение на 15 индексов всего.


Pasha: Dima пишет: Допустим юзер открыл базу в которой 5 индексов. Он может самостоятельно менять сортировку базы (переключая индексы). Понадобилось ему поставить фильтр (аля SCOPE , допустим есть и 6 индекс), он его ставит. И вот тут вопрос каков ключ должен быть у этого индекса что бы не нарушить текущую сортировку и вопрос 2: допустим SCOPE установлен, но при смене юзером сортировки , SCOPE нас покинет так как останется привязанным к 6 индексу и от фильтра аля SCOPE и следа не останется. В общем случае решения эта задача не имеет, так как два управляющих индекса одновременно: один для фильтра, другой для сортировки установить нельзя. А разве в six можно ? Там ограничения точно такие же, чудес не бывает.

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

SergKis: Dima пишет:Жесть. Они у тебя как теги или каждый индекс в отдельном файле ? Как теги. Такую ситуацию не планировал. Начинал с 5 или с 7 уже не помню, но как всегда надо вчера и быстро разные просмотры Browse, Achoice и в течении года накапало. Добавляю теги с опаской, что развалится нах, ан нет - работает. База 22-70М, SMT 55M, словом действительно жесть, но работает.

SergKis: The Mach SIx Query Optimizer:[pre2] The Mach SIx Query Optimizer The Mach SIx Query Optimizer is an integrated system that provides high-speed query optimization for SET FILTER and other selected Clipper commands when used with a FOR condition. Mach SIx optimizes queries by following a procedural set of steps that determine the best access plan to retrieve the requested set of data. Mach SIx's primary focus is on the existence of index key expressions in the FOR criteria of its supported commands and functions. Using this information, Mach SIx is able to directly search the index files to satisfy all or part of the query without ever having to access the database. Once it becomes necessary to query the physical database, Mach SIx only queries the set of records found to meet the condition based on the data in the index files. This means that including just one indexed expression, in the FOR condition, has the potential to narrow the scope of the query to a very small set of the original file. This translates to incredible speed gains for any optimized command that contains one or more index key expressions. Queries that used to take minutes, now return in seconds. In some cases, you will experience performance increases that are magnitudes above standard Clipper. It's completely done for you in the background. If Mach SIx is unable to optimize the query condition, it simply turns control over to standard Clipper, but when it can, you'll see Clipper sail, and sail like it never has before. [/pre2]

Dima: [pre2] Структура базы "naim","c",20,0 "kod1","n",2,0 "kod2","n",2,0 "kod3","n",2,0 есть 4 индекса indeks on naim to test1 indeks on kod1 to test2 indeks on kod2 to test3 indeks on kod3 to test4 К базе подключены в следующем порядке use test index test1,test2,test3,test4 Индексы test2,test3,test4 созданы только лишь для оптимизированных фильтров по этим полям. База всегда (в Browse) должна быть отсортирована по алфавиту (поле naim). Ставить нужно примерно вот такие фильтры Set filter to kod1==3 Set filter to kod2==77 Set filter to kod3==12 Set filter to kod1==1 .and. kod2==76 .and. kod3==3 и тд и тп Все эти фильтры будут оптимизированы. Для того что бы реализовать это через Scope , ну скажем вот такой фильтр Set filter to kod1==3 Необходимо иметь индекс с ключиком str(kod1,2)+naim и ставим фильтр: Set scope to " 3"," 3" Аналогично подходим к фильтру Set filter to kod1==1 .and. kod2==76 .and. kod3==3 Необходимо иметь индекс с ключиком str(kod1,2)+str(kod2,2)+str(kod3,2)+naim и ставим фильтр: Set scope to " 1"+"76"+" 3"," 1"+"76"+" 3" Если же на том же индексе надо установить фильтр вида Set filter to kod3==3 То вероятно Scope будет выглядеть так Set scope to " 0"+" 0"+" 3","99"+"99"+" 3" Я вообще правильно подхожу к Scope ? ;) [/pre2]

SergKis: Dima пишет:Я вообще правильно подхожу к Scope ? На мой взгляд надо: indeks on naim to test1 indeks on kod1+naim to test2 indeks on kod2+naim to test3 indeks on kod3+naim to test4 indeks on kod1+kod2+kod3+naim to test5 Чтобы не таскать в идекс все наименование, часто достаточно upper(left(naim, 7)) Использовать Scope без filter: Setscope(0,' 3'); Setscope(1,' 3') // 2-4 indeks Setscope(0,' 0 0 3'); Setscope(1,'9999 3') // 5 indeks можно добавить буквы - добавится обрезка на наименование: Setscope(0,' 3A'); Setscope(1,' 3A') // 2-4 indeks Setscope(0,' 0 0 3C'); Setscope(1,'9999 3C') // 5 indeks

Dima: А разве индекс SergKis пишет: indeks on kod1+kod2+kod3+naim to test5 Не заменит вот эти 3 ? SergKis пишет: indeks on kod1+naim to test2 indeks on kod2+naim to test3 indeks on kod3+naim to test4

SergKis: Dima пишет:Не заменит вот эти 3 ? Для Scope нет. Вы же хотите Set scope " 1"+"76"+" 3"," 1"+"76"+" 3" Этот scope частично замет test2, если отбросить наименование. Вы задаете Scope ключ слева по длине не > длины от индексного выражения, т.е. для index5 можно задать " 1"+"76" и " 1"+"7" и " 1"+"76"+" " и " 1"+"76"+" 3"+"ABC"

Dima: SergKis пишет: Для Scope нет Не так меня поняли видимо. Я имел в виду что индекс вида indeks on kod1+kod2+kod3+naim to test5 в состоянии решить все виды SCOPE которые предоставляют вот эти 3 индекса indeks on kod1+naim to test2 indeks on kod2+naim to test3 indeks on kod3+naim to test4 Зачем заводить 3 идекса если можно сделать один который решит те же задачи по SCOPE. Или я не прав ?

Pasha: Dima пишет: Структура базы "naim","c",20,0 "kod1","n",2,0 "kod2","n",2,0 "kod3","n",2,0 есть 4 индекса indeks on naim to test1 indeks on kod1 to test2 indeks on kod2 to test3 indeks on kod3 to test4 К базе подключены в следующем порядке use test index test1,test2,test3,test4 Индексы test2,test3,test4 созданы только лишь для оптимизированных фильтров по этим полям. База всегда (в Browse) должна быть отсортирована по алфавиту (поле naim). Ставить нужно примерно вот такие фильтры Set filter to kod1==3 Set filter to kod2==77 Set filter to kod3==12 Set filter to kod1==1 .and. kod2==76 .and. kod3==3 и тд и тп Все эти фильтры будут оптимизированы. А разве six и ads решает эту задачу ? Здесь как раз имеется различные индексы для фильтра (2,3,4) и для сортировки (1). А два управляющих индекса одновременно использовать нельзя. Одно индексное выражение должно решать обе эти задачи. Фильтр по scope может быть только по левой части индексного выражения.

SergKis: Dima пишет:решит те же задачи по SCOPE. Как задать scope по index5 только для kod3+name или только для kod2+name, если слева в ключе kod1 ?

Dima: SergKis пишет: Как задать scope по index5 только для kod3+name или только для kod2+name, если слева в ключе kod1 ? Легко. Если kod2,kod1,kod3 цифры я же показывал такую выборку Dima пишет: Необходимо иметь индекс с ключиком str(kod1,2)+str(kod2,2)+str(kod3,2)+naim и ставим фильтр: Set scope to " 1"+"76"+" 3"," 1"+"76"+" 3" Если же на том же индексе надо установить фильтр вида Set filter to kod3==3 То вероятно Scope будет выглядеть так Set scope to " 0"+" 0"+" 3","99"+"99"+" 3" то есть для kod1 и kod2 я указал нижнюю и верхнюю границы то есть выбраны будут все записи с любыми kod1 и kod2 и kod3==3 Pasha пишет: Фильтр по scope может быть только по левой части индексного выражения. Да я понял это. Pasha пишет: А два управляющих индекса одновременно использовать нельзя. я про такое и не говорил , возможно я не так выразился и меня поняли не верно ;)

SergKis: Dima пишет:Легко. Если kod2,kod1,kod3 цифры я же показывал такую выборку Для kod3 да, а для только kod2+name нет, т.е. index5 частично что то решает. Так у меня и появились 48 тегов у dbf.

Dima: SergKis пишет: Для kod3 да, а для только kod2+name Да точно так же решается

AlexMyr: SergKis пишет: На мой взгляд надо: indeks on naim to test1 indeks on kod1+naim to test2 indeks on kod2+naim to test3 indeks on kod3+naim to test4 indeks on kod1+kod2+kod3+naim to test5 Достаточно: indeks on naim+kod2 to test3 indeks on naim+kod3 to test4 indeks on naim+kod1+kod2+kod3 to test5 индекс test5 будет удовлетворять и test1: setscope(0,"naim") setscope(1,"naim") и test2 setscope(0,"naim"+"kod1") setscope(1,"naim"+"kod1")

AlexMyr: Еще поясню, есть у меня такое индексное выражение "TBN+STR(Y0,4,0)+STR(M0,2,0)+STR(VOU)" Выбираем: все записи по конкретному таб ном ordscope(0," 1") ordscope(1," 1") все записи по конкретному таб ном + по заданному году ordscope(0," 1"+"2013") ordscope(1," 1"+"2013") все записи по конкретному таб ном + по заданному периоду года ordscope(0," 1"+"2010") ordscope(1," 1"+"2013") все записи по конкретному таб ном + по заданному году + по заданному месяцу ordscope(0," 1"+"2013"+" 1") ordscope(1," 1"+"2013"+" 1") все записи по конкретному таб ном + по заданному году + по заданному месяцу+по заданному виду ordscope(0," 1"+"2013"+" 1"+"100") ordscope(1," 1"+"2013"+" 1"+"100") Т.е. как уже говорили, начинаем с левой части индексного выражения.

Dima: Еще примерчик. [pre2] index on str(kmcod,6)+str(codgr,6) to klient ordscope(0," 0") ordscope(1," 3") Выберет из базы записи с kmcod от 0 до 3 включительно , проверил пашет ordscope(0," 3"+" 61") ordscope(1," 3"+" 61") Выберет из базы записи с kmcod 3 и codgr==61 , проверил пашет А вот так не работает как ожидалось ordscope(0," 0"+" 61") ordscope(1," 3"+" 61") то есть выборка по kmcod правильная а по codgr нет и встречаются записи с codgr # 61 где я не прав ? [/pre2] Выходит что если задана правая и левая часть то в этом случае в левой части не может быть задан диапазон , в то время как в правой части это допустимо. То есть так не сработает правильно ordscope(0," 0"+" 61") ordscope(1," 3"+" 61") А вот такого плана Scope сработает верно ordscope(0," 3"+" 61") ordscope(1," 3"+" 77")

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+..., т.к. запросы, как правило, начинаются с периода. В данном случае такой тег с датой дополнительно иметь не помешает.



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