Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 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.062 c
15-1350333002
Юрий
2012-10-16 00:30
2013.03.22
С днем рождения ! 16 октября 2012 вторник


9-1193300178
SergGG
2007-10-25 12:16
2013.03.22
Перевод координат в OpenGL


4-1261045077
Гном11
2009-12-17 13:17
2013.03.22
Что вместо WinSingt в Delphi 2006


15-1343315733
brother
2012-07-26 19:15
2013.03.22
С днем системного администратора


15-1333892049
xayam
2012-04-08 17:34
2013.03.22
mono ttf utf-8





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский