Необходимы мудрые мысли со стороны. Ибо... на перепутье. :(

Используется PB9 + Oracle7.3

Есть необходимость реализовать в приложении фильтрацию значений. Соответственно надо накладывать какие-то условия на выборку. dw.sefFilter( {тра-ля-ля} ) не подходит, т.к. он подразумевает предварительное выкачивание всей выборки. Альтернатива - каждый раз получать только то, что нужно, т.е. условия фильтрации в запросе.
Существует три (по крайней мере я больше не вижу) возможных решения:
1. dw.getSqlSelect() => правим раздел Where ручками => dw.setSqlSelect( {новый select} ).
2. dw.retrieve( {дофига параметров} ).
3. dw.object.dataWindow.syntax => злостно правим раздел where => dw.create( {новый синтаксис DW} ).

У всех трех я вижу минусы:
1. Придет DBA и со словами "какого ... у тебя каждый запрос имеет собственный план..." в общем будут проблемы.
2. поскольку пользователь не обязан указывать ВСЕ параметры для фильтра, то в запросе должно быть что-то похожее на "( age = @age or @age is null )". Но при этом насколько я понимаю шерстится вся таблица а индексы как бы не причем... т.е. производительность этого безобразия тоже несколько не высока (т.к. предполагается, что параметров в retrieve будет... много).
3. Предыдущих минусов тут нет, т.к. мы просто убираем из where те условия которые не важны пользователю. Соответственно, план запроса (естественно, что для одинакового набора указанных пользователем полей в фильтре) будет один. Но.... черт побери! Со стороны это смотрится порядочным извращением. Навыки формирования синтаксиса DW ручками у меня есть, но извращения на то и извращения, что бы быть редкими, а не являться естественным способом работы!

Очень интересуют мнения о разрешении ситуации и особенно собственный выбор/опыт (желательно с объяснением "почему так").

2 urvas
urvasМожно QueryByExample попробовать
В смысле?

2 urvas
Я к концу недели видимо совсем не соображаю уже. :(
1. Меня сбило с толку Query ByExample .
2. Я не улавливаю как мне это может помочь. :(

2 Black Savage
Насколько я понимаю это "расширенный" вариант 3 в моем списке. Только у меня идет речь исключительно о фильтре, а здесь, по большому счету, пользователю позволятся полностью конструировать результирующий список (в том числе и по составу полей). Я правильно понимаю?

2 urvas
urvasСпособ, конечно, примитивный и применим, на мой взгляд, больше к DW-grid.
А смысл в следующем - надо открыть датавиндов в режиме запроса, ввести нужные для отбора данные и выполнить запрос.
Это - вкратце.
Да я, в общем то понял... проблема в том, что такой способ в принципе не вписывается (интерфейсно-идеологически) в проект. Да и (честно говоря) мне он совсем не нравится.

2 ytrewq
ytrewqРешения 1 и 3 друг от друга, на мой взгляд, ничем не отличаются...
И да и нет. В третьем варианте присутствуют параметры в dw.retrieve(...), что лучше воспринимается сервером. Хотя надо признать, что в аспекте правки раздела where это действительно близнецы братья (вся разница, что в одном случае подставляется "age = 32", а в другом "age = :age").

ytrewqГлавное, не впадать в моразм. Мне известен случай, когда положив в основу тезис "какого ... у тебя каждый запрос имеет собственный план...", ребятки использовали способ "дофига параметров" + универсальная функция поиска на PL-SQL. На реальных объемах базы (связка 5-7 таблиц, в некоторых по паре миллионов записей) такие запросы отрабатывали 5-15-30 минут (это те, которые хватило терпения дождаться). Мне это объяснили тем, что при этом запрос повторно не парсится на ORACLE. Пришлось переписывать всю эту мутотень.
Вот именно это меня и смущает в варианте 2... там индексы игнорируются (по крайней мере на Оракле 7.3), что при больших объемах таблиц может удручающе влиять на скорость.

В общем... честно говоря я не получил того, что ожидал. Я почему-то думал, что мое сообщение спровоцирует спор между сторонниками разных вариантов. А в результате я внимательно послушав смогу оценить минусы разных вариантов. Ведь кто лучше оппонента укажет на все недостатки? А может и еще какие интересные (для меня) мысли мелькнут. ;) Но увы... :(

В целом я склоняюсь к третьему варианту. Т.е. в retrieve() перечисляется тьма параметров, а потом по необходимости ручками правится раздел where, что бы избежать условий типа "( age = :age or :age is null )" (точнее использование конструкций: "... or :age is null").

2 Геннадич
ГеннадичТоварищ намекает на ороклячьи хинты, только я не знаю работают они в семёрке или нет, но в любом случае злоупотреблять хинтами не рекомендую. А вот по поводу процедурки - это правильно. Передать в процедурку кучу аргументов, она посмотрит какие Null или не Null и через динамический SQL вернёт в REF курсор то что надо.
К сожалению не пойдет. Я бы сам может так и сделал, но у нас четкое разделение на тех, кто пишет на клиенте и на тех, кто пишет на сервере... с понятными последствиями. :(

2 ytrewq
ytrewq ДремучийВот именно это меня и смущает в варианте 2... там индексы игнорируются (по крайней мере на Оракле 7.3), что при больших объемах таблиц может удручающе влиять на скорость.
Oracle может игнорировать индексы, но может и не игнорировать - тут "неправда Ваша".
Мне на примерах (по принципу "age = :age or :age = 0") было продемонстрировано, что игнорирует... Может быть в других версиях (у нас 7.3) по другому, но мы имеем то что имеем.

ytrewq ДремучийВ общем... честно говоря я не получил того, что ожидал. Я почему-то думал, что мое сообщение спровоцирует спор между сторонниками разных вариантов. А в результате я внимательно послушав смогу оценить минусы разных вариантов. Ведь кто лучше оппонента укажет на все недостатки? А может и еще какие интересные (для меня) мысли мелькнут. ;) Но увы... :(
Единого рецепта здесь, к сожалению, нет, посему, наверное, и нет предмета спора. Практически во всех разработках (по крайней мере, у меня) присутствуют все варианты.
Я как раз и рассчитывал, что единого варианта нет, а значит апологеты разных вариантов могут и схлестнуться чей канон веры каноничнее. ;) Я ошибся. ;)

ytrewq ДремучийВ целом я склоняюсь к третьему варианту. Т.е. в retrieve() перечисляется тьма параметров, а потом по необходимости ручками правится раздел where, что бы избежать условий типа "( age = :age or :age is null )" (точнее использование конструкций: "... or :age is null").
Категоричные высказывания грозят в дальнейшем всеми теми неприятностями, про которые Вы и так знаете. Да, вдогонку, изменение фразы where в третьем варианте автоматически ведет к повторному разбору на сервере всего запроса.
А где Вы здесь увидели "категоричность"? ;)

А по поводу "изменение фразы where". Угу. Но (насколько я понимаю) при повторном использовании фразы одного типа повторного разбора не будет. Т.е., если в реальной работе в 90-95% случаев используется 2-3 варианта задания условий для фильтра (например, "фамилия", "фамилия и год рождения" и "фамилия и имя" ), то в большинстве случаев новых планов создаваться не будет. А вот если указывать "в лоб" (по типу "family = 'Иванов'"), то практически каждое обращение к БД будет инициировать составление нового плана.

ytrewqВам бы лучше перенестись с этим топиком в форум по Oracle, там получите гораздо больше информации по этому вопросу ...
Мне кажется нет. Это скорее Билдеровский вопрос, но с учетом особенностей Оракла... впрочем, это уже лирика.

2 gal20
gal20В свое время был использован механизм получения выборок при разных входных ограничениях - сначала во временную таблицу на основе входных параметров складывались значения PK, а потом они использовались в запросе единственного DW для отображения пользователю.
Это немного другой случай. У нас тонкое место не в изначальном построении выборки, а в постоянном изменении условий одной выборки (результат постоянного использования пользователем фильтра).

2 Anatoly Moskovsky
Anatoly Moskovsky ДремучийМне на примерах (по принципу "age = :age or :age = 0") было продемонстрировано, что игнорирует... Может быть в других версиях (у нас 7.3) по другому, но мы имеем то что имеем.


Вообще в зависимости от режима оптимизации и наличия статистики такой запрос может быть преобразован оптимизатором в конкатенацию запросов:
=>

При этом скорее всего будет использован индекс по a.

Для принудительного включения такой трансляции можно использовать хинты use_concat, first_rows

В 7.3 эти хинты есть.
Хм... а во что это превратиться, если параметров у retrieve будет полтора-два десятка (это абсолютно реальный вариант)?
Т.е. до оптимизации будет:
а после???

2 ytrewq
ytrewqГлянул на продолжение дискуссии. Чуть более понял постановку вопроса. Почти во всем с Вами согласен.
Это плохо. Я бы предпочел, что бы это я с вами согласился.

ytrewq Кроме вот этой фразы
ДремучийЭто скорее Билдеровский вопрос, но с учетом особенностей Оракла... впрочем, это уже лирика.

Это чисто Oracle-вский вопрос. Пишите клиента на чем угодно. Все равно вопросы будут одни и те же.
Не согласен. И дело не только в том, то в MS SQL тоже "что то есть". Дело в том, что механизм передачи условия задается/обрабатывается/формируется на клиенте! Соответственно и те проблемы которые при этом возникают можно оценить только на клиенте. Соотвественно надо знать в первую очередь Билдер (в разных СР разные тараканы), а потом СУБД. Это "имхо", конечно.

2 Anatoly Moskovsky
Anatoly Moskovsky2) Естественно что злоупотреблять хинтом use_concat не стоит, так как при громоздких условиях слишком большое время затрачивается на компиляцию запроса с большим кол. подзапросов в union all (бывало вообще сервер зависал :))
Угу. :(. Испольование конструкции "( age = :age or :age is null )" намекает, что конструкций такого типа будет очень много с весьма вероятными последствиями для быстродействия. :(

2 Anatoly Moskovsky
Anatoly MoskovskyИспользуйте способ 3 из Вашего начального сообщения.
Не вижу в нем никаких сложностей или извращений.
Мне казалось, что одновременная правка раздела where и передача параметров через retrieve несколько нелогична (по логике, либо то, либо то). Соотвественно в этом есть что-то извращенное.

2 PL99
Anatoly MoskovskyIMHO, черезчур сложно, проще править Table.Select
Вы правы. Так и сделано. Просто, когда я начинал ветку, я предполагал, что это не работает (по аналогии с setSQLSelect()). Отсюда и самый жестокий вариант (что, кстати, и "увеличивает" извращенность ;)

2 Anatoly Moskovsky
Anatoly MoskovskyЕму требуется менять и перечень аргументов DW (из-за требования DBA не зашивать значения фильтра в код запроса, а использовать bind-переменные), а это можно только так сделать:
Да это так, но зачем менять список аргументов? Можно ведь просто часть не использовать и все (что я и сделал).

Anatoly Moskovsky ДремучийДа это так, но зачем менять список аргументов? Можно ведь просто часть не использовать и все (что я и сделал).
Это к вопросу об оптимизации a = :a or :a is null.

Если вырезать из where условия где аргумент null, то СУБД сможет нормальный план построить, а иначе - всегда Full Table Scan с последующим повешаньем пользователями и ДБА :)
То ли Вы меня не понимаете, то ли я Вас... Я делаю так:
1. Список аргументов в retrieve максимально полон (во время рисования в painter`е).
2. Условий в where нет вообще никаких (во время рисования в painter`е). Естественно, что какие-то условия могут быть (например, если данные из БД не удаляются, а помечаются как удаленные, то "удаленные" нужно отсечь сразу).
3. При использовании фильтра (или еще при какой надобности). Смотрится какие аргументы отличны от null/0/'' (и т.п.) и соответственно для этих аргументов вносится (добавляется к "базовому" условию в where, если оно есть, конечно) их упоминание в раздел where (по типу "a = :a").

Для этих телодвижений достаточно править dw.object.datawindow.table.select.

Anatoly Moskovsky ДремучийДля этих телодвижений достаточно править dw.object.datawindow.table.select.
Странно, я всегда думал что при использовании аргументов datawindow.table.select нельзя менять. Или это только про SetSQLSelect ?
:) Я тоже так думал. Поэтому тоже первоначально писал о dw.create()

OK.

Anatoly MoskovskyТут у меня одна идейка возникла, уже по реализации, применимая к обоим подходам, чтобы упростить модификацию where.

Берем dw.syntax или select и делаем
ls_arg = "a"
ls_syntax = s.of_GlobalReplace(ls_syntax, ls_arg + " = :" + ls_arg, " 1=1 ")
для тех арг., где null.

А затем create() или dw.object.datawindow.table.select =
... при использовании строгого равенства это пройдет, хотя смотреться будет некрасиво, а вот при минимальном расширении уже нет. Поэтому лучше сразу написать механизм, который добавляет условия. Если что, то потом будет проще добавлять функционал.

PL99 ДремучийОчень интересуют мнения о разрешении ситуации и особенно собственный выбор/опыт (желательно с объяснением "почему так").Не уверен, поддерживает ли это 7.3, но, тем не менее Ну и вот
Судя по заголовку:
Переменные связывания и совместное использование курсоров: новые тенденции в СУБД Oracle9i
в 7.3. этого нет. Но я, на всякий случай, подниму этот вопрос. Спасибо!

2 Estets
EstetsВообщем вопрос а стоит ли данная овчинка выделки?
Вот этот вопрос меня очень сильно интересовал. Но по тому как протекало обсуждение я сделал вывод, что подавляющее большинство с постановкой вопроса под таким углом просто не сталкивалось (лично я столкнулся недавно).

2 zuzu
zuzuк вопросу об оптимизации a = :a or :a is null.
я всегда использую конструкцию типа:

Хм... а план выполнения что показывает? На 7.3. у нас такая конструкция пошла шерстить всю таблицу не взирая на индексы. :(

2 savosin_sergey
savosin_sergey2 народ:
народ! поясните пожалуйста, чем плоха перекомпиляция плана? сервер долго его составляет? он в тихую выстраивает индексы? сам я работаю с mssql2000, с проблемой перекомпиляции не встречался
Насколько я понимаю (сам с такой проблемой фактически сейчас столкнулся, до этого то ли на MS SQL2000 это не такая проблема, то ли DBA мне не попадался внимательный) проблема в том, что постоянная перекомпиляция плана очень хорошо загаживает кеш при работе большого количества пользователей. Если посмотреть ссылку PL99 , то там написано следующее "Значения 1234 и 5678 в двух примерах, показанных выше, являются константами (литералами), их использование в операторах SQL является причиной возникновения накладных расходов из-за дополнительных разборов и означает, что операторы SQL в библиотечном кеше не разделяются."
Насколько это страшно (на сколько падает производительность) мне сказать трудно, но у нас DBA начал шуметь.

2 savosin_sergey
Из той же ссылки:
Как было показано в предыдущем разделе, при просмотре библиотечного кеша только полностью идентичные операторы SQL будут считаться идентичными. Следовательно, два оператора:

select * from emp where empno=1234
и

select * from emp where empno=5678
считаются различными и для их выполнения потребуются два полных разбора и две отдельных записи в библиотечном кеше. Вот почему настоятельно рекомендуется для связывания значений в прикладной программе использовать в операторах SQL переменные связывания, фактические значения которых подставляются только во время выполнения программы. Оператор, показанный выше, теперь будет таким:

select * from emp where empno=:x

Его можно выполнять много раз с различными значениями переменной связывания :x. В хорошо написанном приложении будет выполняться один разбор этого оператора, затем его можно выполнять столько раз, сколько требуется, с различными значениями переменной связывания в прикладной программе. Такой подход не только повышает производительность одной программы, он также обеспечивает масштабируемость многочисленных параллельно работающих программ, разделяющих одну и ту же копию данного оператора SQL. Корпорация Oracle рекомендует при программировании приложений всегда использовать этот подход.