Здравствуйте.
Столкнулся с такой проблемой. Делаю относительно большой, но однотипный запрос. Придумал 2 варианта реализации: много запросов объединенных union или один запрос с использованием decode().
В оптимизации я практически 0. Какой вариант лучше использовать для быстродействия?
Привожу уменьшенные запросы (возвращают только 2 строки/столбца, а готовый запрос будет содержать около 25).
1) Выполняет просмотр X строк, истинное время порядка 470 (из sql+) или около 3 сек (из PL/SQL Developer) 

2) Выполняет просмотр X * (число подзапросов) строк, истинное время порядка 430 (из sql+) или около 0,5 сек (из PL/SQL Developer) 

То есть второй вроде строк в разы больше лопатит, но выполняется быстрее... Так какой вариант оптимальнее???
ЗЫ. В итоге буду тянуть данные из базы в прогу на делфи через DOA, если это имеет какое-то значение...

При наличии индексов по id_brig или id_material, второй запрос может их использовать, в то время как первый - full scan однозначно.
Надо смотреть планы.

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

зы зачем тебе union? union это всяко сортировка, которая тут лишняя, хоть и стоит мало. Используй union all, и возьми себе в бест практис не использовать union пока это дейтсвтельно не будет нужно )

  

хз... как раз думал об этом сейчас... просто в моей древней книжке как-то это не описано...
я использую с all когда подзапросы могут одинаковые строки возвращать и мне нужно чтобы они все выбирались, а во всех остальных случаях я без all пишу  
по юнион подведем краткий итог: юзать с all кроме тех случаев, когда не нужны дублирующиеся строки, правильно я понял, Zloxa?

Достаточно просто помнить что union инициирует сортировку. Такую же, как при указании distinct. Ты же интуитивно не лепишь дистинкт где ни попадя ;)

А чо там с планами? не покажешь?
Причем план лучше смотреть на удаленном сервере, наверняка запрос туда транслируется полностью 

Это как понять? Я со своего компа делаю запросы в базу которая на сервере находится...

Зачем тогда указание дибилинка?

Или в шестерке так принято?

Zloxa, кажись понял... с собакой это я под своим пользователем запрос пишу... а нужно план под пользователем, которому таблица принадлежит?

прости, я не знаю особенностей шестерки, но начиная с восмерки указывается схема.таблица@база_данных.
Пользователь, является владельцем схемы.
Т.о. если ты формируешь запрос к таблице в той же базе, но для таблицы из схемы другого пользователя, ты пишешь user.table.
Когда ты указываешь собаку, это подразумевает, что ты собираешься получить данные от другой базы данных(от другого сервера), не о той, с которой ты соединен.

В принципе у каждой базы данных есть dblink на самою себя. 
Если дибилинк, который ты указываешь, есть дибилинк "на себя", то тогда можно смотреть план из твоей сессии 

Не, я в чужую базу запрос делаю...
Планы (законнектился в чужую базу):

в первом плане забыл собаку убрать.

Обрати внимание, что по плану, он фетчит весь набор данных с удаленного сервера, а фильтр и  группировку выполняет на своей стороне.

Возможно второй запрос он транслирует полностью на ту сторону, и фетчит всего две строки.

  блин, что за день сегодня, совсем невнимателен :(
завтра отредактирую нормально, т.к. сейчас нет возможности...

Добавлено через 4 минуты и 6 секунд
Zloxa, а тот запрос, который в чужой базе (где таблица) оптимальнее работает, тот и из моей базы лучше отработает или может быть наоборот?

По всякому может быть.
План показал второй запрос что индексы не использует.
По какой причине он отрабатывает быстрее, мне, лично не ясно.
Как гепотеза. Первый запрос выполняет фильтрацию набора данных и аггрегацию на вызывающей стороне.  Второй запрос, возможно транслируется на удаленную сторону полностью(надо посмотреть план с вызывающего сревера), принимает уже готовый результат.

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


Это сообщение отредактировал(а) Kbl4AH - 26.3.2009, 21:18

Присоединённый файл ( Кол-во скачиваний: 4 )
 Querys.rar 1,03 Kb

C моей точки зрения, таки первый запрос будет наименее эффективен для энергетиков, а значит более подходит нам - программистам ;)

В обоих случаях фильтрация и аггрегация производится на вызывающей стороне, во втором случае, один и тот же набор данных сканируется и фетчится дважды. Если честно, я недоумеваю, по моему запрос веьсма прост, и оракля должен бы сообразить что тянуть одну запись по линку таки проще нежели 1210. Была бы то не шестерка, пожалуй предложил бы поиграться хинтом driving_site (select /*+driving_site(t)*/ ... from table@link t ...) но уееренности в том что это помогло бы даже на десятке у меня нет. Обычно этот хинт реально помогает, когда мы объединяем два набора данных, один с вызывающей стороны, другой с удаленной. Оракля, не имея статистики удаленного узла, может не угадать на какой стороне выполнять запрос(какой набор данных больше). ОДнако в случае с одним набором данных, весьма странно, что он выбирает вызывающую сторону а не удаленную.

Эммм, не понял... так какой запрос ты считаешь лучше: с юнион или с декоде?
с декоде?

Это сообщение отредактировал(а) Kbl4AH - 27.3.2009, 10:44