Alex.CzechВ MS SQL одно из наиболее частых применений временных таблиц - сказать
INSERT INTO #ttable
EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно>
Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ?
Один из вариантов решения, предложенного в ASA:
1.
SELECT *
FROM StoredProcedure (@Param1, @Param2);
Если в теле процедуры только SELECT, то она воспринимается как представление и разворачивается в план запроса, если еще какой то код, то она выполняется, автоматом результат передается в внутреннюю рабочую таблицу и уже она далее фигурирует в плане запроса. Использование ХП в запросах было бы неполным, если бы в ASA еще не добавили LATERAL соединение:
1.
2.
SELECT *
FROM Table1 t
LATERAL StoredProcedure (@Param1 = t.Field1, @Param2 = t.Field2);
Такое соединение позволяет для каждой записи Table1 вызвать процедуру с поддержкой передачи в виде параметров полей запроса. Оптимизация будет выглядеть так же - если в процедуре только SELECT, то он развернется в основной план запроса. Это же соединение можно использовать и для организации подзапросов:
1.
2.
3.
4.
5.
6.
SELECT t1.Field1, g.Max_Field2
FROM Table1 t1,
LATERAL (
SELECT Max(Field2) AS Max_Field2
FROM Table2 t2
WHERE t2.Field1 = t1.Field1
) AS g;
Как видим, фактически LATERAL является аналогом Subquery, внутри которого можно обращаться к полям основной таблицы, который часто применяется в секциях SELECT и WHERE. Однако в отличие от Subquery соединение LATERAL реализовано в оптимизаторе собственным оптимизированным алгоритмом и работает гораздо быстрее из за того, что ASA его разворачивает в основной план запроса и соотвествующе более оптимально использует статистику и индексы при его выполнении. В основном такой способ соединения очень выгоден для разделения сложного запроса, где используются куча подзапросов, в которых множество очень обьемных таблиц и получается выгоднее на записи основного запроса через SingleRowGroup организовать аггрегации через LATERAL, чем уломать оптимизатор всю эту страшную кучу правильно соединить. При правильном использовании можно некоторые запросы ускорять в 10-ки раз, плюс это позволяет почаще отказываться от времянок и держаться в проекте главной линии ASA - никаких хинтов в запросах для СУБД с нулевым администрированием, только оптимизатор вправе решать в зависимости от содержания БД, чего и как лучше (хотя естественно это применимо только к СУБД класса Workgroup, а уж никак к хранилищам данных, где есть живой админ, который всегда лучше знает свою БД).
