Стиль письма запроса 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, не вижу смысла повторяться ))

Пит (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 своими нареканиями конкретно на работу оптимизатора со мной делились и другие разработчики. Хотя в остальном равного этому серверу по возможностям и элегантности синтаксиса я ничего не встречал, если честно.

Аббат Пиккола (13.11.12 14:46) [31]

Это от непонимания принципов работы оптимизатора Oracle. Бывает.

← →
Аббат Пиккола (2012-11-13 14:55) [33]

Куда уж нам уж.... Скромным аббатам. Мы за пониманием и не гонялись. Мы гонялись за предельной скоростью. И добивались всеми правдами и неправдами. И хинты писали и структуры базы улучшали. Ну далеко нам до истинных ценителей, которые наслаждаются глубокой философией "стоимостной оптимизации"... что теперь поделаешь.

Аббат Пиккола (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 помню, с таким опытом это уже не Тролль, это мастер )

заводите свои ветки и там собачьтесь :)

← →
Аббат Пиккола (2012-11-13 16:12) [39]

Да-да точно. Сам Данте упоминает об Игоре.
Точнее о том, как мы Игорем Шевченко (Слава ему!) спускаемся куда-то, чтобы начать знакомство с токументацие ORACLE в части работы оптимизатора. Помню как сейчас эти строки...

Я, прочитав над входом, в вышине,
Такие знаки сумрачного цвета,
Сказал: «Учитель, смысл их страшен мне».

Он, прозорливый, отвечал на это:
"Здесь нужно, чтоб душа была тверда;
Здесь страх не должен подавать совета.

Я обещал, что мы придем туда,
Где ты увидишь, как томятся тени,
Свет разума утратив навсегда".

Дав руку мне, чтоб я не знал сомнений,
И обернув ко мне спокойный лик,
Он ввел меня в таинственные сени.

Там вздохи, плач и исступленный крик
Во тьме беззвездной были так велики,
Что поначалу я в слезах поник.

← →
Пит (2012-11-13 16:16) [40]

> заводите свои ветки и там собачьтесь :)

да мы твою в топе держим! чем недоволен то)

Стиль письма запроса SQL. Плохо? Найти похожие ветки