ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PowerBuilder [игнор отключен] [закрыт для гостей] / Организация фильтра на DW
25 сообщений из 56, страница 2 из 3
  2  все
Организация фильтра на DW
    #33935589
Дремучий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дремучий
Участник
2 Anatoly Moskovsky
Anatoly MoskovskyИспользуйте способ 3 из Вашего начального сообщения.
Не вижу в нем никаких сложностей или извращений.
Мне казалось, что одновременная правка раздела where и передача параметров через retrieve несколько нелогична (по логике, либо то, либо то). Соотвественно в этом есть что-то извращенное.

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

2 Anatoly Moskovsky
Anatoly MoskovskyЕму требуется менять и перечень аргументов DW (из-за требования DBA не зашивать значения фильтра в код запроса, а использовать bind-переменные), а это можно только так сделать:
Да это так, но зачем менять список аргументов? Можно ведь просто часть не использовать и все (что я и сделал).
...
Рейтинг: 0 / 0
22.08.2006, 17:32
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935615
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
ДремучийДа это так, но зачем менять список аргументов? Можно ведь просто часть не использовать и все (что я и сделал).
Это к вопросу об оптимизации a = :a or :a is null.

Если вырезать из where условия где аргумент null, то СУБД сможет нормальный план построить, а иначе - всегда Full Table Scan с последующим повешаньем пользователями и ДБА :)
...
Рейтинг: 0 / 0
22.08.2006, 17:39
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935655
Дремучий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дремучий
Участник
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.
...
Рейтинг: 0 / 0
22.08.2006, 17:55
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935715
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
ДремучийДля этих телодвижений достаточно править dw.object.datawindow.table.select.
Странно, я всегда думал что при использовании аргументов datawindow.table.select нельзя менять. Или это только про SetSQLSelect ?
OK.

Тут у меня одна идейка возникла, уже по реализации, применимая к обоим подходам, чтобы упростить модификацию 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 =
...
Рейтинг: 0 / 0
22.08.2006, 18:11
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935775
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
Anatoly MoskovskyБерем dw.syntax или select и делаем
ls_arg = "a"
ls_syntax = s.of_GlobalReplace(ls_syntax, ls_arg + " = :" + ls_arg, " 1=1 ")
для тех арг., где null.
Не все так просто, а диапазоны дат и чисел, а поиски по подстроке?
...
Рейтинг: 0 / 0
22.08.2006, 18:30
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935816
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
ДремучийОчень интересуют мнения о разрешении ситуации и особенно собственный выбор/опыт (желательно с объяснением "почему так").Не уверен, поддерживает ли это 7.3, но, тем не менее
Код: plaintext
alter session set cursor_sharing=force
Ну и вот
...
Рейтинг: 0 / 0
22.08.2006, 18:47
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935827
Дремучий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дремучий
Участник
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 =
... при использовании строгого равенства это пройдет, хотя смотреться будет некрасиво, а вот при минимальном расширении уже нет. Поэтому лучше сразу написать механизм, который добавляет условия. Если что, то потом будет проще добавлять функционал.
...
Рейтинг: 0 / 0
22.08.2006, 18:52
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935840
Дремучий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дремучий
Участник
PL99 ДремучийОчень интересуют мнения о разрешении ситуации и особенно собственный выбор/опыт (желательно с объяснением "почему так").Не уверен, поддерживает ли это 7.3, но, тем не менее
Код: plaintext
alter session set cursor_sharing=force
Ну и вот
Судя по заголовку:
Переменные связывания и совместное использование курсоров: новые тенденции в СУБД Oracle9i
в 7.3. этого нет. Но я, на всякий случай, подниму этот вопрос. Спасибо!
...
Рейтинг: 0 / 0
22.08.2006, 18:57
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33935867
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
Estets Anatoly MoskovskyБерем dw.syntax или select и делаем
ls_arg = "a"
ls_syntax = s.of_GlobalReplace(ls_syntax, ls_arg + " = :" + ls_arg, " 1=1 ")
для тех арг., где null.
Не все так просто, а диапазоны дат и чисел, а поиски по подстроке? Общий подход сформулирован давно, надо только реализовать его так, чтобы у DBA не было поводов для наезда :-)
У нас пока все по простому, без bind-переменных.
...
Рейтинг: 0 / 0
22.08.2006, 19:13
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33936571
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
PL99 Estets Anatoly MoskovskyБерем dw.syntax или select и делаем
ls_arg = "a"
ls_syntax = s.of_GlobalReplace(ls_syntax, ls_arg + " = :" + ls_arg, " 1=1 ")
для тех арг., где null.
Не все так просто, а диапазоны дат и чисел, а поиски по подстроке? Общий подход сформулирован давно, надо только реализовать его так, чтобы у DBA не было поводов для наезда :-)
У нас пока все по простому, без bind-переменных.
Я конечно могу ошибаться, поскольку ORALE знаю хуже, но использование bind-переменных в данном случае это стандартная работа DW - неизменная часть WHERE выражения. И вся прелесть фильтрации в которой аргументы NULL приводят удалению части WHERE выражения, пропадает. Cерверу придется парсить и перестраивать план запроса?

Хотя с другой стороны если основной объем запросов к серверу показать документ
Код: plaintext
WHERE id =  123456789
И кучу перечней к нему
Код: plaintext
WHERE master_id =  123456789
То замена на bind переменные master_id = :master_id дадут выигрыш производительности по сравнению с прямой подстановкой констант в WHERE.

Но в таких случаях (если не считать пост "Вопрос по использованию/работе n_cst_dwsrv_linkage") не используется сложная динамическая фильтрация и исправления WHERE выражений тут не требуется.

Вообщем вопрос а стоит ли данная овчинка выделки?
...
Рейтинг: 0 / 0
23.08.2006, 10:29
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33936619
zuzu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zuzu
Участник
к вопросу об оптимизации a = :a or :a is null.
я всегда использую конструкцию типа:
Код: plaintext
1.
select * from table_test
where nvl(:ID_FIELD,ID_FIELD) = ID_FIELD
...
Рейтинг: 0 / 0
23.08.2006, 10:38
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33936722
Фотография savosin_sergey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
savosin_sergey
Участник
2 народ:
Дремучий
1. Придет DBA и со словами "какого ... у тебя каждый запрос имеет собственный план..." в общем будут проблемы.

народ! поясните пожалуйста, чем плоха перекомпиляция плана? сервер долго его составляет? он в тихую выстраивает индексы? сам я работаю с mssql2000, с проблемой перекомпиляции не встречался
...
Рейтинг: 0 / 0
23.08.2006, 10:59
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33936869
Дремучий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дремучий
Участник
2 Estets
EstetsВообщем вопрос а стоит ли данная овчинка выделки?
Вот этот вопрос меня очень сильно интересовал. Но по тому как протекало обсуждение я сделал вывод, что подавляющее большинство с постановкой вопроса под таким углом просто не сталкивалось (лично я столкнулся недавно).

2 zuzu
zuzuк вопросу об оптимизации a = :a or :a is null.
я всегда использую конструкцию типа:
Код: plaintext
1.
select * from table_test
where nvl(:ID_FIELD,ID_FIELD) = ID_FIELD

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

2 savosin_sergey
savosin_sergey2 народ:
народ! поясните пожалуйста, чем плоха перекомпиляция плана? сервер долго его составляет? он в тихую выстраивает индексы? сам я работаю с mssql2000, с проблемой перекомпиляции не встречался
Насколько я понимаю (сам с такой проблемой фактически сейчас столкнулся, до этого то ли на MS SQL2000 это не такая проблема, то ли DBA мне не попадался внимательный) проблема в том, что постоянная перекомпиляция плана очень хорошо загаживает кеш при работе большого количества пользователей. Если посмотреть ссылку PL99 , то там написано следующее "Значения 1234 и 5678 в двух примерах, показанных выше, являются константами (литералами), их использование в операторах SQL является причиной возникновения накладных расходов из-за дополнительных разборов и означает, что операторы SQL в библиотечном кеше не разделяются."
Насколько это страшно (на сколько падает производительность) мне сказать трудно, но у нас DBA начал шуметь.
...
Рейтинг: 0 / 0
23.08.2006, 11:28
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33936887
Дремучий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дремучий
Участник
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 рекомендует при программировании приложений всегда использовать этот подход.
...
Рейтинг: 0 / 0
23.08.2006, 11:32
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33937108
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
В хороших СУБД есть автоматическая параметризация запросов :)
...
Рейтинг: 0 / 0
23.08.2006, 12:20
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33937211
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
Estetsиспользование bind-переменных в данном случае это стандартная работа DW - неизменная часть WHERE выражения.Правильно, но речь идет о том, чтобы вообще не использовать retrieval аргументы. Дело в том, что в наших приложениях практически не встречаются ситуации, когда сотни пользователей выполняют один и тот же запрос с разными аргументами, поэтому запросы так или иначе вытесняются из кэша сервера.

Сейчас я выскажу крамольную мысль, но тем не менее...
В OLTP системах подавляющее большинство запросов составляют вставки и изменения, просмотры же встречаются гораздо реже. Т.е., операторы вводят первичную информацию, а выбор значений из справочников нересуроемкая операция - редко когда в справочниках больше нескольких тысяч значений, чаще порядка 10-100, в противном случае применяются альтернативные подходы, например сканер штрихкодов. Но тогда принципиально меняется интерфейс пользователя, а значит, ничего не мешает использовать bind-переменные


EstetsВообщем вопрос а стоит ли данная овчинка выделки?Во-во :-)
Короче, мы не заморачиваемся, DBA не может запретить, может только рекомендовать изменить подход для каких-то особенно критичных запросов.
...
Рейтинг: 0 / 0
23.08.2006, 12:42
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33937220
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
Локшин МаркВ хороших СУБД есть автоматическая параметризация запросов :)Oracle 7.3 уже не менее 10 лет, тогда, видимо, это было не столь актуально :-)
...
Рейтинг: 0 / 0
23.08.2006, 12:44
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33937359
Фотография savosin_sergey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
savosin_sergey
Участник
PL99
Сейчас я выскажу крамольную мысль, но тем не менее...
В OLTP системах подавляющее большинство запросов составляют вставки и изменения, просмотры же встречаются гораздо реже. Т.е., операторы вводят первичную информацию, а выбор значений из справочников нересуроемкая операция - редко когда в справочниках больше нескольких тысяч значений, чаще порядка 10-100, в противном случае применяются альтернативные подходы, например сканер штрихкодов. Но тогда принципиально меняется интерфейс пользователя, а значит, ничего не мешает использовать bind-переменные


речь, возможно, идёт не о справочниках, а об интерфейсе master-detail. перещёлкнул строку в master -- новый запрос из detail отправляется на сервер.. может пользователи данные и просматривают реже, чем вводят , но строк в подчинённой таблице может быть очень много. master -- шапки документов, а detail -- строки документов. их больше, чем строк в master'е!

к тому же обычно (а может это только мне обычно) ввод информации совмещён с просмотром.. например, хочется просмотреть, чего-же ты такого назаводил только что. всё зависит от постановки задачи.
...
Рейтинг: 0 / 0
23.08.2006, 13:13
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33937835
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
По теме чем плохо, что каждый запрос парсится.

На самом деле при хорошем проектировании системы этой проблемы вообще нет.

Проблемы начинаются, когда, из-за недостатка денег, опыта, ума и пр., объединяют в одном физическом сервере интенсивный OLTP и интенсивный OLAP. В этом случае запросы OLTP должны выполняться максимально быстро, а так как для них время исполнения сравнимо с временем парсинга, то кеширование отпарсенных запросов может значительно поднять производительность при массовых OLTP. Если же параллельно массово делается OLAP с множеством разных запросов (например вебпоисковик), то запросы OLTP вытесняются из кеша и снижается их производительность.

Поэтому при массовых операциях OLTP + OLAP, надо обязательно использовать bind-аргументы. Или просто разнести эти два типа операций на разные сервера.

Эта комбинация встречается не так уж и часто, мне вот на ум приходит только вебпоисковик (массовые изменения в базе+массовые запросы по базе).

Так что в обычной жизни посылайте своего ДБА куда подальше, поскольку вряд ли у вас именно такой проект.
...
Рейтинг: 0 / 0
23.08.2006, 15:08
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33942059
Фотография spas2001
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
spas2001
Участник
Ребята, планы исполнения это заботы админов
тем более, почему вы думаете что значения null приводят к
полному сканированию таблицы (неуникальный индекс вполне работает)
И get-set sql вполне приемлемый способ
Значения сразу вписываются в sql и все работает(раз уж процедуру не хочется писать). Можно также выбрать все данные и накладывать фильтр на клиенте, но это зависит от обьема данных. Использование хинтов чревато последствиями (откуда вы знаете как собрана, допустим, та же статистика)
...
Рейтинг: 0 / 0
25.08.2006, 09:47
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33942085
Фотография spas2001
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
spas2001
Участник
Не помню уже как в 7-ке (давно уже не использовал), а в 8-ке и тем более в9-ке, оптимизер уже сам может делает перепривязку, ну а план выполнения составляется куда быстрее чем вы думаете (не делайте проблему из выбора плана- на это уходит меньше времени чем вы думаете и зависит от грамотности написания запросов и настроек сервера ). Если понадобится админ сам укажет узкое место и подскажет. Работать надо в команде
...
Рейтинг: 0 / 0
25.08.2006, 09:59
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33942120
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
spas2001Ребята, планы исполнения это заботы админов
тем более, почему вы думаете что значения null приводят к
полному сканированию таблицы (неуникальный индекс вполне работает)
А это фича такая
http://www.dba-oracle.com/oracle_tips_ault_nulls_values.htm
странно что Вы об этом спрашиваете, если используете Oracle.
spas2001Использование хинтов чревато последствиями (откуда вы знаете как собрана, допустим, та же статистика)
Эээ, как раз скорее наоборот в отсутствии нормальной статистики.
...
Рейтинг: 0 / 0
25.08.2006, 10:10
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33942250
Фотография spas2001
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
spas2001
Участник
Марк, что это за админ который не собирает статистику?
Деньги он за что получает?
И потом, любой нормальный админ уже давно нормально автоматизировал этот процесс
...
Рейтинг: 0 / 0
25.08.2006, 10:44
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33942306
Фотография spas2001
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
spas2001
Участник
А насчет первой фичи, положение дел несколько изменилось (если найду дам ссылку)
Во-вторых, правильная настройка оптимизера тоже немаловажна
В-третьих, при больших обьемах данных иной раз выгоднее использовать именно полное сканирование таблицы.
И последнее, кто сказал, что план выполнения всегда верно отображает стоимость запроса
...
Рейтинг: 0 / 0
25.08.2006, 10:56
| Ответить | Цитировать | Написать  
Организация фильтра на DW
    #33942315
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
spas2001Марк, что это за админ который не собирает статистику?
Деньги он за что получает?
И потом, любой нормальный админ уже давно нормально автоматизировал этот процесс
Никто не говорит что нужно везде hint'ы расставлять, но если задаваться вопросом про то "откуда мы знаем как собрана статистика?", то вполне тогда логично задаться вопросом "а откуда мы знаем есть ли там вообще админ?".
...
Рейтинг: 0 / 0
25.08.2006, 10:58
| Ответить | Цитировать | Написать  
25 сообщений из 56, страница 2 из 3
  2  все
Форумы / PowerBuilder [игнор отключен] [закрыт для гостей] / Организация фильтра на DW
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=15&msg=33935655&tid=1337628]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 86ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 60ms
get tp. blocked users:
 2ms
others: 239ms
total:  434ms
созд. / загр.: 434ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]