Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сложный JOIN таблиц [D7, FireBird 1.5]

palva © (2006-08-25 17:48:00)
Сабж встречается у меня в хранимой процедуре - четыре таблицы, одна из них два раза. Стоит ли попытаться сделать все это несколькими запросами с хранением промежуточных результатов в переменных? Или оптимальнее будет оставить сложный запрос?

palva (2006-08-28 15:18:00) [1]
Спасибо всем.

Sergey13 (2006-08-28 10:59:00) [2]
Что то частенько обсуждение вопросов по любым БД стало перескакивать на Оракл.
К чему бы это? 8-)

Desdechado (2006-08-28 10:46:00) [3]
> оракл перебирает всего не более 20 вариантов
Зависит от настроек Оракла.

evvcom (2006-08-28 09:07:00) [4]
> [7] Desdechado © (27.08.06 15:59)
> Я заметил, что Оракл начинает тупить с планами запросов,
> когда используется более 6 таблиц в одном запросе. Тогда
> оптимизатор просто не успевает или не желает рассматривать
> все дерево вариантов планов и получаются "кривульки".

Количество всех вариантов планов равно (Ntab - 1)! Естественно, что все варианты перебирать - это терять кучу времени на переборах. По-моему, оракл перебирает всего не более 20 вариантов, причем вроде как не все подряд, а по его оценкам возможных кандидатов. Иногда он неверно оценивает количество записей из-за параметров или участия в запросе пользовательских функций и/или таблиц-функций. В таких случаях я ему помогаю хинтами :), но все равно стараюсь делать это в одном запросе.

Desdechado (2006-08-27 15:59:00) [5]
palva © (25.08.06 17:48)
Если логика запроса не вывихнутая, то лучше одним запросом обойтись. Если же вывихи есть, развесь их по отдельным (возможно, вложенным) запросам.

> ANB © (25.08.06 18:01) [4]
Я заметил, что Оракл начинает тупить с планами запросов, когда используется более 6 таблиц в одном запросе. Тогда оптимизатор просто не успевает или не желает рассматривать все дерево вариантов планов и получаются "кривульки". Разбиением этих запросов часто скорости увеличиваются на порядок.

Как с этим у IB/FB, не замечал.

palva (2006-08-25 20:07:00) [6]
> Что мешает поэксперементировать?
Не врубился в это пока.

unknown (2006-08-25 18:18:00) [7]

> palva © (25.08.06 17:58) [3]

Что мешает поэксперементировать? Сделать так и так и так и...
При этом проанализировать планы, время выполнения, количество чтений и т.п.

ANB (2006-08-25 18:01:00) [8]

> palva © (25.08.06 17:58) [3]

4 курсора по маленьким запросам везде работают помедленнее, чем один по большому. Ресурсы типа жрут и все такое. Я разбиваю на куски либо если оракла не дает запрос впихнуть в хранимку, либо если мозгов не хватает грамотно запрос написать. Кстати, потери небольшие, а вот если большой запрос плохо написать, то тормоза будут еще больше.
Но на 4-х таблицах - это довольно простой запрос.

palva (2006-08-25 17:58:00) [9]
Отдельные запросы ведь тоже будут использовать индексы. У меня впечатление, что оптимизатор кода процедур существенно хуже работает, чем оптимизатор запросов.

ANB (2006-08-25 17:56:00) [10]

> Если JOIN по индексированным полям

А если не по индексированным - проидексировать и все равно JOIN.

StriderMan (2006-08-25 17:50:00) [11]
Если JOIN по индексированным полям, то лучше конечно JOIN.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »