Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
ВнизСтиль письма запроса SQL. Плохо? Найти похожие ветки
← →
AV © (2012-11-13 09:01) [0]Мысль такая, после where
сразу пишем 1=1
потом любая строка начинается с and
where 1=1
and U.us_regdate > sysdate - 90
and GA.ID_AGENT = 146
допустим, надо закоментить любую строку
where 1=1
and U.us_regdate > sysdate - 90
-- and GA.ID_AGENT = 146
работает, ничего удивительного
но и
where 1=1
-- and U.us_regdate > sysdate - 90
and GA.ID_AGENT = 146
тоже работает.
если писать так
where
U.us_regdate > sysdate - 90
and GA.ID_AGENT = 146
или так
where
U.us_regdate > sysdate - 90 and
GA.ID_AGENT = 146
не любую строку можно закомментировать, чтобы сохранилась работоспособность запроса.
Против есть?
← →
pavel_guzhanov © (2012-11-13 09:22) [1]Я работаю в системе пенсионного учета "Пегас". В ней есть возможность собственной разработки, которая ведется на SQL. Также там реализовано наследование. И вот, чтобы правильно парсить запрос, у верхнего предка в where пишется 1 = 1, а в потомках уже and ...
Так что я, если чо, не против :о))
← →
AV © (2012-11-13 09:33) [2]:)
я про оптимизатор. Его не передернет, интеерсно. Ну так, теоретически
← →
Игорь Шевченко © (2012-11-13 10:10) [3]
> Против есть?
есть
← →
AV © (2012-11-13 10:15) [4]
> есть
why?
← →
Игорь Шевченко © (2012-11-13 11:14) [5]
> why?
зачем тебе комментировать строки ?
← →
Аббат Пиккола (2012-11-13 11:25) [6]А left join вообще отменяется?
← →
pavel_guzhanov © (2012-11-13 11:30) [7]left join на больших объемах - тормоза жуткие
← →
AV © (2012-11-13 11:37) [8]
> зачем тебе комментировать строки ?
Ну как..
Примерно результат известен. Надо найти закономерность.
Добавляем условия, добавляем - немного не то получается. Убираем некоторые.
Возможно, первое(последнее) тоже.
В сформированном запросе помечаем "--" и выделяем в конструкторе эти строки серым.
Наглядно и не надо распарсивать заново.
> А left join вообще отменяется?
не понял тебя
но
join (left) еще до where идет
там как раз комментировать удобно. Единственное, что не удобно
по умолчанию стиль
TABLE_A A
join TABLE_B B
on B.ID_A = A.ID_B
сам пишу немного не по стандарту конторы,
TABLE_A A
join TABLE_B B on B.ID_A = A.ID_B
приходится перед сохранением жмакать по кнопке "wonderful code"
зато опять же удобно
TABLE_A A
-- join TABLE_B B on B.ID_A = A.ID_B
join TABLE_С бла-бла
или
TABLE_A A
join TABLE_B B on B.ID_A = A.ID_B
-- join TABLE_С бла-бла
и нагляднее и проще.
имхо
← →
Медвежонок Пятачок © (2012-11-13 11:41) [9]Мысль такая, после where
Мысль верная.
А то сначала напишешь десятиэтажный запрос, а затем тебе говорят, у нас в него не попадает какая-то хрень.
И для для выяснения причин такой стиль самое то
← →
Аббат Пиккола (2012-11-13 11:52) [10]А почему не делать практически все на join-ах? А к where прибегать как раз в редких случаях. Ведь join позволяет лучше контролировать ситуацию с декартовым произведением, которое легко случайно получить, добавляя и удаляя условия в WHERE в десятиэтажных запросах.
Спрашиваю просто так. Сам предпочитаю писать WHERE, но я редко работаю с гигантскими объемами и не работаю в корпорации. Но если бы работал в конторе, возможно, сразу отказался бы от WHERE.
← →
Аббат Пиккола (2012-11-13 11:53) [11]к тому же inner join-ы легко сочетать с left join-ами. а иногда последние все же бывают нужны, хотя и каждый раз требут осмысления, особенно при использовании агрегатных функций совместно с ними.
← →
Аббат Пиккола (2012-11-13 11:56) [12]Причем есл речь идет об ORACLE, то я замечал (пусть меня поправят - не гарантирую, что мне не почудилось), что оптимизатор ORACLE при построении плана запроса ОБРАЩАЕТ внимание на последовательность объединений, если использована явно конструкция JOIN.
← →
Игорь Шевченко © (2012-11-13 11:57) [13]AV © (13.11.12 11:37) [8]
"Кривое не может сделаться прямым" (Еккл. 1, 15)
← →
wicked © (2012-11-13 12:04) [14]
> я про оптимизатор. Его не передернет, интеерсно. Ну так,
> теоретически
грош цена оптимизатору, которого такое передернет
хотя - всегда надо смотреть на план запроса
> А почему не делать практически все на join-ах? А к where
> прибегать как раз в редких случаях. Ведь join позволяет
> лучше контролировать ситуацию с декартовым произведением,
> которое легко случайно получить, добавляя и удаляя условия
> в WHERE в десятиэтажных запросах.
>
> Спрашиваю просто так. Сам предпочитаю писать WHERE, но я
> редко работаю с гигантскими объемами и не работаю в корпорации.
> Но если бы работал в конторе, возможно, сразу отказался
> бы от WHERE.
у них разное назначение:
- в join условия служат для присоединения строки таблицы; если условие в left join не выполнилось - срочка не присоединилась и в соотв полях у тебя появились NULL
- в where - для фильтрации готового набора данных; там уже ты или принимаешь, или отбрасываешь всю строку целиком
в общем, иногда углы можно и срезать, но понимать разницу между тем, где ты разместил условие - надо
← →
Пит (2012-11-13 12:06) [15]
> left join на больших объемах - тормоза жуткие
какая потрясающая штука сказана )) Кстати, right join то наверное быстрее? )
Неужели left join при наличии where по rowid на оракле будет жутко тормозить?
> Против есть?
нету.where 1=1
очень распространенный способ приписать условие, чтобы потом динамически подставлять условия фильтрации " ... and ...". В любом случае статическое условие будет разобрано, детерминировано и на скорость работы не повлияет. По крайней мере это условие не будет коррелировать с количеством записей,а сама обработка условия займет крайне маленькое время.
← →
Компромисс © (2012-11-13 12:14) [16]Ответ зависит от автора. Если код генерится автоматически, то почему бы и нет. Особенно, если запрос генерится одним классом, а потом к нему access level фильтр применяет другой класс.
Если же запрос пишется ручками, то нефиг добавлять лишнее условие. Читается хуже, а читаться он будет гораздо чаще, чем меняться комментированием условия.
← →
AV © (2012-11-13 12:21) [17]
> А почему не делать практически все на join-ах?
так и делаю
Но, тем не менее, where часто тоже большой получается
т.е. фильтров на выборку штук 10
> А то сначала напишешь десятиэтажный запрос, а затем тебе
> говорят, у нас в него не попадает какая-то хрень.
Во-во-во! %)
> Кривое не может сделаться прямым
Бывает, что бы легче считать было, есть смысл изменить систему отсчета :)
← →
Игорь Шевченко © (2012-11-13 12:27) [18]мне к [16] нечего добавить.
← →
Аббат Пиккола (2012-11-13 12:35) [19]При на самом деле автоматической генерации запросов как-то обхожусь без 1=1. Мне не лень добавить слово WHERE, если набралось хотя бы одно условие для WHERE. И добавить первый AND, если нашлось второе условие для WHERE. А при ручном составлении запросы особых преимуществ или недостатков в 1=1 не вижу, хотя сам редко так пишу.
Вопрос к знатокам ORACLE. Так мне показалось или все же оптимизатор ORACLE обращает внимание на последовательность явных inner join-ов?
← →
Игорь Шевченко © (2012-11-13 12:42) [20]Аббат Пиккола (13.11.12 12:35) [19]
> все же оптимизатор ORACLE обращает внимание на последовательность
> явных inner join-ов?
не обращает.
> При на самом деле автоматической генерации запросов как-
> то обхожусь без 1=1. Мне не лень добавить слово WHERE, если
> набралось хотя бы одно условие для WHERE. И добавить первый
> AND, если нашлось второе условие для WHERE. А при ручном
> составлении запросы особых преимуществ или недостатков в
> 1=1 не вижу, хотя сам редко так пишу.
Необходимость в (1=1) бывает, например, при динамической подстановке условий выборки в следующий запрос:SELECT foo, bar, bazz
FROM (SELECT f.foo, b.bar, b.bazz
FROM f,b
WHERE f.a IN (SELECT ....
WHERE ...
AND ..)
)
WHERE (1=1)
-- ADD FILTER HERE
-- ADD FILTER HERE
ORDER BY ....
← →
AV © (2012-11-13 12:47) [21]
> > все же оптимизатор ORACLE обращает внимание на последовательность
> > явных inner join-ов?
>
>
> не обращает.
т.е.
совет начать с "меньшей" таблицы, присоединяя в порядке возрастания объемов - лишен основания?
(например, в 10g)
← →
Пит (2012-11-13 12:49) [22]
> совет начать с "меньшей" таблицы, присоединяя в порядке
> возрастания объемов - лишен основания?
абсолютно. Гораздо круче выучить хинты
← →
Игорь Шевченко © (2012-11-13 12:51) [23]AV © (13.11.12 12:47) [21]
> совет начать с "меньшей" таблицы, присоединяя в порядке
> возрастания объемов - лишен основания?
Лишен.
Пит (13.11.12 12:49) [22]
> Гораздо круче выучить хинты
Этот совет тоже лишен основания, за исключением полного замораживания продукта на конкретной версии сервера Oracle
← →
Компромисс © (2012-11-13 13:05) [24]Аббат Пиккола (13.11.12 12:35) [19]
У меня есть какой-то автоматически сгенерированный запрос, о котором ничего неизвестно. Есть класс, который должен добавить условия типа "AND (field1=? OR field2=?...), количество и значения полей зависят от пользователя, для которого сгенерирован запрос. Должен ли я парсить неизвестный запрос, чтобы определить его тип:
1) без where: добавляем WHERE (field1=? OR field2=?...)
2) с where и AND: where field1=?: добавляем AND (field1=? OR field2=?...)
3) c where и OR: where field1=1 or field2=?: заключаем существующие условия в скобки добавляем AND (field1=? OR field2=?...)
По-моему, гораздо проще заставить автоматически сгенерированный запрос быть готовым к тому, чтобы к нему добавлялось AND (field1=? OR field2=?...)
То есть:
1) where 1=1
2) where field1=?
3) where (field1=1 or field2=?)
← →
Пит (2012-11-13 13:07) [25]
> Этот совет тоже лишен основания
как так. Чем плохо выучить хинты? )
> за исключением полного замораживания продукта на конкретной
> версии сервера Oracle
приведите пример, когда грамотный хинт, ускоряющий выборку - на следующий версии оракла приводит к замедлению выборки по сравнению с отсутствием этого хинта?
← →
Игорь Шевченко © (2012-11-13 13:46) [26]
> приведите пример, когда грамотный хинт, ускоряющий выборку
> - на следующий версии оракла приводит к замедлению выборки
> по сравнению с отсутствием этого хинта?
Примеры приводит Джонатан Льюис в "Основах стоимостной оптимизации", не вижу смысла копировать
← →
Аббат Пиккола (2012-11-13 14:07) [27]Помнится, что выбор политики оптимизации как-то напрямую OPTIMIZERMODE определялся. Это вроде был глобальный параметр? Или сейчас можно прямо в запросе (хинте) это оговорить? Давно с ORACLE не общался - просто инетерсно.
← →
Пит (2012-11-13 14:10) [28]
> Примеры приводит Джонатан Льюис в "Основах стоимостной оптимизации"
ну тогда не понимаю что вы вообще на форумах делаете ))
На 99% тем можно ответить: об этом сказано в книге автора xxx под названием yyy, не вижу смысла повторяться ))
← →
Игорь Шевченко © (2012-11-13 14:13) [29]Пит (13.11.12 14:10) [28]
Я не понимаю, что ты тут делаешь, но этот недостаток легко исправим :)
Аббат Пиккола (13.11.12 14:07) [27]
> Или сейчас можно прямо в запросе (хинте) это оговорить?
Можно глобально, можно в запросе.
> Давно с ORACLE не общался - просто инетерсно.
Имеет смысл документацию почитать
← →
Пит (2012-11-13 14:28) [30]Удалено модератором
Примечание: Offtopic
← →
Аббат Пиккола (2012-11-13 14:46) [31]Если можно оговорить в запросе выбор политики оптимизации "по правилам" вместо "по стоимости", то тогда Пит тоже прав - в ряде случаев я бы предпочел оптимизацию, заданную проектировщиком (мной), так как, признаюсь, то, что выдавал оптимизатор ORACLE, не всегда устраивало. Может сейчас он стал каким-нибудь суперским, не знаю. Но в ORACLE 9i своими нареканиями конкретно на работу оптимизатора со мной делились и другие разработчики. Хотя в остальном равного этому серверу по возможностям и элегантности синтаксиса я ничего не встречал, если честно.
← →
Игорь Шевченко © (2012-11-13 14:49) [32]Аббат Пиккола (13.11.12 14:46) [31]
Это от непонимания принципов работы оптимизатора Oracle. Бывает.
← →
Аббат Пиккола (2012-11-13 14:55) [33]Куда уж нам уж.... Скромным аббатам. Мы за пониманием и не гонялись. Мы гонялись за предельной скоростью. И добивались всеми правдами и неправдами. И хинты писали и структуры базы улучшали. Ну далеко нам до истинных ценителей, которые наслаждаются глубокой философией "стоимостной оптимизации"... что теперь поделаешь.
← →
Игорь Шевченко © (2012-11-13 15:01) [34]Аббат Пиккола (13.11.12 14:55) [33]
Это точно. Возмущаться осатаневшей цензурой куда проще. На этом предлагаю оффтопик закончить.
← →
Пит (2012-11-13 15:15) [35]
> Мы за пониманием и не гонялись
да ты не переживай ))
В любой крупной промышленной системе на оракле ты встретишь хинты. Оно, конечно, наверное да, что всё должно быть спроектировано так, чтобы оптимизатор сам разобрался. И он зачастую разбирается, накапливает статистику, время от времени меняет план запроса и так далее. Но практика есть практика, иногда начинает тормозить и тебе скажут "Слишком долгий отклик от системы". И появляется хинт.
В конце концов разработчики оракла ВСТРОИЛИ систему хинтов в сервер, о чем речь? Значит, они сами считают, что она иногда нужна.
И мистер критикующий на 100% точно также эти хинты использует, но пофлудить про коня в вакууме почему бы и нет, главное не говорить никакой конкретики - иначе самого начнут критиковать. А если что - отослать к книжке, перевести стрелки )) Очень удобно, вот что такое опыт )
А так - используются хинты и вовсю используются, когда нетривиально лопатят данные в десятки сотни гигабайт - почти всегда используют.
← →
Аббат Пиккола (2012-11-13 15:16) [36]Вы, сударь, и есть тролль.
Причем толстый.
← →
Пит (2012-11-13 15:50) [37]Да я Игоря еще по FIDO7.RU.DELPHI помню, с таким опытом это уже не Тролль, это мастер )
← →
AV © (2012-11-13 16:09) [38]заводите свои ветки и там собачьтесь :)
← →
Аббат Пиккола (2012-11-13 16:12) [39]Да-да точно. Сам Данте упоминает об Игоре.
Точнее о том, как мы Игорем Шевченко (Слава ему!) спускаемся куда-то, чтобы начать знакомство с токументацие ORACLE в части работы оптимизатора. Помню как сейчас эти строки...
Я, прочитав над входом, в вышине,
Такие знаки сумрачного цвета,
Сказал: «Учитель, смысл их страшен мне».
Он, прозорливый, отвечал на это:
"Здесь нужно, чтоб душа была тверда;
Здесь страх не должен подавать совета.
Я обещал, что мы придем туда,
Где ты увидишь, как томятся тени,
Свет разума утратив навсегда".
Дав руку мне, чтоб я не знал сомнений,
И обернув ко мне спокойный лик,
Он ввел меня в таинственные сени.
Там вздохи, плач и исступленный крик
Во тьме беззвездной были так велики,
Что поначалу я в слезах поник.
← →
Пит (2012-11-13 16:16) [40]
> заводите свои ветки и там собачьтесь :)
да мы твою в топе держим! чем недоволен то)
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.56 MB
Время: 0.059 c