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

Используется 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 )" намекает, что конструкций такого типа будет очень много с весьма вероятными последствиями для быстродействия. :(