Один запрос 0.5 сек, такой же изменный 15 сек 8(

← →
AntiUser © (2006-10-06 22:07) [0]

Этот запрос выполнется за доли секунды (сколько раз его не повторяй):
SELECT Fond.fond, Invent.invent, Invent.tom, Business.* FROM Business, Invent, Fond Where Business.invent_id = Invent.invent_id and Invent.fond_id = Fond.fond_id and (fond = 9) and (lower(business_desc) like "%сидор%") ORDER BY fond, invent, Business.business, litera nulls first, Part nulls first, headerpart nulls first

А эот же но записанный несколько подругому выполняется 15 сек. (сколько раз его не повторяй):
SELECT Fond.fond, Invent.invent, Invent.tom, Business.* FROM Business LEFT OUTER JOIN invent ON Business.invent_id = Invent.invent_id LEFT OUTER JOIN fond ON Invent.fond_id = Fond.fond_id WHERE (fond = 9) and (lower(business_desc) like "%сидор%") ORDER BY fond, invent, Business.business, litera nulls first, Part nulls first, headerpart nulls first

Объясните в чем дело?

← →
Palladin © (2006-10-06 22:14) [1]

имхо
left outer join и просто join (он же inner, в общем то, и есть простое жесткое условие привязки id"шников) довольно разные вещи на уровне СУБД и запросов и выполнение зависит от механизмов их реализации...

хотя вполе справедливо преполагать что outer будет выполняться дольше...

← →
jack128 © (2006-10-06 22:16) [2]

AntiUser © (06.10.06 22:07)
Такие вещи зависят от особенностей реализации конкретной СУБД. А так как СУБД не указана, то и вопрос особого смысла не имеет..

← →
AntiUser © (2006-10-06 22:30) [3]

СУБД Oracle9i

← →
Palladin © (2006-10-06 22:34) [4]

ms sql for ever!!! :)

← →
Kerk © (2006-10-06 22:36) [5]

> [4] Palladin © (06.10.06 22:34)

изыди!

← →
Palladin © (2006-10-06 22:40) [6]

сам такой!

← →
tesseract © (2006-10-06 22:47) [7]

> Kerk © (06.10.06 22:36) [5]

Чертим круг :-)

А так Oracle Outer Join любить не должен, ибо объектный он. И структура таблиц не указана. Запихни в хранимку и посмотри результат.

А вот если время исполнения одинаковго запроса не изменяеться от кол-ва его вызовов, то ИМХО у тебя ORacle не так настроен.

← →
Johnmen © (2006-10-06 23:12) [8]

Внешние соединения всегда и во всех серверах медленнее в разы, нежели внутренние. В общем случае...

← →
Anatoly Podgoretsky © (2006-10-07 00:52) [9]

Запросы не адекватны, убели LEFT OUTER

← →
AntiUser © (2006-10-07 01:25) [10]

tesseract © (06.10.06 22:47) [7]
Запихни в хранимку и посмотри результат.

О чем мы тут говорим? Какие хранимые процедуры? В принципе я знаю что это, но чтобы это запихнуть в "хранимку", на это у меня знаний не хватит =( (пока не хватит, я быстро учусь)

P.S. Если вам не трудно запихните, пожалуйста, а я хоть посмотрю, как это выглядит, ну и заодно протестю.

P.S.S Не в коем слусае не настаиваю, чтобы не подумали чего.

P.S.S.S Книжку с соответствуещей информацией собираюсь приобрести, только в 20-ых числа (финансовые проблемы), потом почитать, потом попробовать и снова почитать. Думаю в начале ноября "хранимку" напишу сам. =)))))

← →
vecna © (2006-10-07 11:13) [11]

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

← →
AntiUser © (2006-10-07 11:50) [12]

vecna © (07.10.06 11:13) [11]
планы обоих запросов в студию

Всмысле планы? Оба запроса в первом посте. Если писать функцию, то я не совсем понимаю механизм (но в будущей книжке я надеюсь об этом узнать), как вернуть все найденные записи, например, примерно так:
Вернуть ВСЕ найденные записи содержащие в поле business_desc текст SearchStr
function SomrFC(SearchStr in varchar2) return <все найденные записи> is <фиг го знает>; begin SELECT Fond.fond, Invent.invent, Invent.tom, Business.* Into Result FROM Business, Invent, Fond Where Business.invent_id = Invent.invent_id and Invent.fond_id = Fond.fond_id and (lower(business_desc) like SearchStr) ORDER BY fond, invent, Business.business, litera nulls first, Part nulls first, headerpart nulls first Return(Result) end SomrFC;

← →
Sergey Masloff (2006-10-07 12:39) [13]

Что внутренние всегда медленнее внешних или наоборот это неправда. Всегда можено сделать пример в котором утверждение неверно.

Без плана запросов сказать ничего нельзя, но конечно надо план посмотреть. При изменении внешний-внутренний план может сильно поменяться. Возможно стоит на него взглянуть и все станет ясно

← →
AntiUser © (2006-10-07 17:01) [14]

Короче, ясно. сначало надо прочитать книжку, а то я даже не знаю, что такое "план запросов". До сегодняшнего дня обходился простыми селектами, но возникла необходимость ускорить процесс. Вот и обнаружил то, что описано в первом посте, поэтому и спросил.
А меня тут уже в такие дебри потянули ... =))))

← →
Anatoly Podgoretsky © (2006-10-07 17:13) [15]

Не нужен пока план запросов, надо привести запросы к единой форме, к INNER JOIN

> Sergey Masloff (07.10.06 12:39) [13]
>
> Что внутренние всегда медленнее внешних или наоборот это
> неправда. Всегда можено сделать пример в котором утверждение
> неверно.

Потому и сказано, что в общем случае. Запросы автора под него подпадают...

> P.S.S.S Книжку с соответствуещей информацией собираюсь приобрести,
> только в 20-ых числа (финансовые проблемы), потом почитать,
> потом попробовать и снова почитать. Думаю в начале ноября
> "хранимку" напишу сам. =)))))

Книга рулит. Срочно баить :-)

← →
Sergey Masloff (2006-10-07 21:20) [18]

Johnmen © (07.10.06 18:07) [16]
Это за рамки темы выходит... Ты ж не знаещь статистики таблиц, реальной и той которую знает оптимизатор, не знаешь даже настройку оптимизатора... Так что даже общим врядли тут случай можно назвать.

← →
Sergey Masloff (2006-10-07 21:21) [19]

Даже неизвестно есть ли индекс функциональный по lower(business_desc)

> Sergey Masloff (07.10.06 21:20) [18]

А телепатор на что? :)

← →
Sergey Masloff (2006-10-07 22:31) [21]

Один запрос 0.5 сек, такой же изменный 15 сек 8( Найти похожие ветки