>ANB   (27.04.09 13:55) [38]
>Если у меня хинт ordered и я начинаю играть порядком обхода, то при >неявном объединении мне надо будет только поменять местами >таблицы во фроме (вырезать+вставить). А при явном - переделывать >текст запроса.
а потом, например, dba врубает plan stability, и вся система идет под откос
хинты - это зло, зло и зло)

Кщд   (27.04.09 14:53) [39]


> так, вообще говоря, (+) не эквивалентен left/right outer
> join


"Три следующих запроса, в первом из которых используется старый синтаксис, семантически одинаковы:

SELECT c.course_name, c.period,
 e.student_name
FROM course c, enrollment e
    WHERE c.course_name = e.course_name(+)

        AND c.period = e.period(+);

SELECT c.course_name, c.period,
 e.student_name
FROM course c LEFT OUTER JOIN enrollment e
    ON c.course_name = e.course_name
       AND c.period = e.period;

SELECT c.course_name, c.period,
 e.student_name
FROM enrollment e RIGHT OUTER JOIN course c
    ON c.course_name = e.course_name
       AND c.period = e.period;
"

http://www.oracle.com/global/ru/oramag/march2002/dev_ansi.html


> да и (+)-синтаксис при необходимости full outer join не
> слишком спасает)


не спасает. Когда требуется full outer join ставится full outer join. Беда только в том, что редко требуется :)

> хинты - это зло, зло и зло


Воистину

> full outer join

Сколько раз в жизни вы им пользовались ?

> хинты - это зло, зло и зло
>
>
> Воистину

Ну ну. К сожалению, без них частенько никак.
А если админ попытается угробить работающую систему - так у нас их много.
Будет новый главный админ, всего то и делов. :)

> К сожалению, без них частенько никак


Кривое не может сделаться прямым

> Кривое не может сделаться прямым

1) Ради одного отчета никто не будет переделывать БД
2) Даже если структуру БД сделать идеальной, то конвертить туда данные просто нереально.
3) Все равно придется применять хинты в особо сложных случаях - хэш джойн, распараллеливание запросов. Оптимизатор не идеален.

ANB   (29.04.09 10:11) [46]

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

> Ты пойми простую вещь - я не настаиваю на том, чтобы лично
> ты прекратил пользоваться хинтами, я высказываю свое мнение
> относительно целесообразности использование костылей при
> ходьбе вообще.

Если оптимизатор сразу дает примерно правильный план - я и не хинтую.

>Игорь Шевченко ©   (27.04.09 15:01) [41]
>"Три следующих запроса, в первом из которых используется старый >синтаксис, семантически одинаковы:
говорил о случаях, когда не одинаковы)
например,

>ANB   (29.04.09 14:55) [48]
>Если оптимизатор сразу дает примерно правильный план - я и не хинтую.
каким образом смотрите план?

> ANB  (29.04.2009 14:55:48)  [48]

А если не сразу, а потом, и при этом для обеих случаев, кроме того как выяснили мешает независимому администрированию.

Кщд   (29.04.09 14:56) [49]

А планы в студию для обоих вариантов не затруднит ?

>Игорь Шевченко ©   (29.04.09 19:17) [52]
затруднит)


собственно, об этом и говорил

или ещё пример:
как переписать на (+)-синтаксисе такой запрос

> ORA-01719: оператор внешнего соединения (+) не разрешен
> в операндах OR или IN


Уел :)

Вот что странно - за долгую и многотрудную жизнь ни разу не приходилось сталкиваться с необходимостью составлять подобные запросы.

> каким образом смотрите план?

F5 в девелопере


> Вот что странно - за долгую и многотрудную жизнь ни разу
> не приходилось сталкиваться с необходимостью составлять
> подобные запросы.

Я сталкивался. Когда сталкивался - тогда и писал другим синтаксисом. Но это так редко бывает . . .

>Игорь Шевченко ©   (30.04.09 14:06) [54]
>Вот что странно - за долгую и многотрудную жизнь ни разу не приходилось >сталкиваться с необходимостью составлять подобные запросы.
очень редко, но случалось, поэтому сейчас, когда oracle залатал баги, связанные с join, пишу в join-синтаксисе
собственно, против (+)-синтаксиса ничего против не имею

>ANB   (04.05.09 09:57) [55]
>F5 в девелопере
реальный план можно увидеть только в трейсе
может случиться так, что Вы хинтами оптимизируете пустоту

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

Ну ни разу еще не нарывался. Как задумано - так и работает.

Если план по Ф5 показывает ерунду - запрос висит. Если показывает то, что надо - работает.

Чисто теоретически, есно, возможны расхождения. Пока не нарывался.
Иначе и смысла бы в он-лайн просмотре планов бы не было.

>sniknik ©   (24.04.09 11:08) [23]
> не, конечно и там среди бухгалтеров попадаются отщепенцы,
>  придумали такую вещь как шахматка... но и ее делают. чаще
> всего "поворачивая"  полученный результат на клиенте, делая
> из "высоты" "ширину". можно и на сервере, легко могу сделать
> на access или mssql  но на FB боюсь их синтаксис не пройдет,
>  даже не пытаться не стоит (а трудов чтобы разбираться задача
> не стоит. глупая логика).


Пытаться уже очень давно стоит.
http://delphiplus.org/articles/ib/firebird-2-full-capability/1/index.html

> ANB   (29.04.09 14:55) [48]
> Если оптимизатор сразу дает примерно правильный план - я и не хинтую.

В Firebird это может аукнуться. Например, генеришь IBExpert-ом  тестовых записей миллиона два-три, чтобы скучно ему не было. Выполняешь скрипт - вроде и план правильный подхватился. А потом на реальных данных "вес" индекса другой получается, т.к реальные данные далеко не равномерно распределенные случайные величины, как в генераторе IBExpert-a. И план твоего запроса (имеется в виду внутри ХП) после первого backup/restore "поедет" куда-то. Так что все-таки бывают случаи, когда планы иногда надо указывать явно. Лично у мну есть пример запроса с "дефолтным" планом, выполняющийся за 18 секунд, и "ручным", выполняющимся за миллисекунды.

Зато при переходе от версии к версии (как это было при 1.5 -> 2.0) есть вероятность наступить на очень древние грабли с изменениями в оптимизаторе, когда твоя БД тупо не восстанавливается из бэкапа из-за кривых (по мнению новой версии) статически прописанных планов. И тогда начинается увлекательнейший квест с перелопачиванием штук 800-1000 хранимых процедур. Так что тут есть свои и плюсы и минусы.

Есть еще третий, компромиссный вариант: хинты. Например, когда индексное поле попадает в условие WHERE, то к нему можно прибавлять 0, дабы отключить использование индекса. Такой изврат на данный момент времени дает похожий план запроса на разных версиях оптимизатора.