ASCRUS c1272 Мимо пробегал....

>Ежели напрягает вместо CREATE VIEW написать CREATE FUNCTION, то, конечно, это большая проблема. Прямо таки неразрешимая.

Таки да, проблема. Функции хуже оптимизируются: использование представления в представлении соптимизируется, а вызов функции из функции или функции из представления - нет.

Может что-то изменилось в последнее время, но врядли.
Давайте не применять знания одной СУБД на другую СУБД. В MSSQL inline функции будут аналогом запросов, спокойно войдут в план запроса и прекрасно будут оптимизироваться. Фактически они там тоже, что и использование в запросах ХП у ASA (правда у нее оптимизатор похитрее и сам решает, когда процедуру можно включить как представление в план запросов, а когда лучше результат процедуры оформить как времянку и уже работать в запросе с ним). В MSSQL же это указывается явной конструкцией в самом диалекте описания функций.

Когда деревья были большими, а версии SQL Server еще маленькими - где то 6 с половиной, - довелось мне пересесть с Oracle на этого подростка. И в первые недели я обнаружил удивительную картину - один и тот же, простой по сути, запрос быстрее выполнялся из функции, чем из представления. Да, еще не все Service Puck были поставлены, еще впереди была версия 7.0 - но факт такой был.

Да, чуть не забыл. Уже тогда документация подробно объясняла, на каком этапе происходила компиляция функций и на каком составлся план запроса. А так же рассказывалось, до каких пор план запроса был верен и что надо было сделать, чтобы сервер пересмотрел этот план.

ASCRUSНаверное он имел ввиду все таки не функции, а хранимые процедуры, которые как известно компиляться вместе с планами запросов.

Всем - извините за апечатку. Это были процедуры.

(Уж и забыл, что не было там функций).

vadiminfoТам нельзя было в запросах вызывать функции? Никогда бы не подумал. Хотя в Оракле это две подсистемы PL/SQL и SQL. Тратится время на переключение контекстов. Т.е. злоупотреблять вызовами ф-ий тоже не лучшее из лучшего. Хотя с другой стороны, из-за того, что некоторые запросы могут повторяться многократно в разных запросах их лучше оформить ф-ями. В общем тут бы не плохо им что-нибудь придумать эдакое. Представления тоже не всегда годятся.

Сам никогда не мерял, но помнится писалось, что функция ТОЛЬКО с входными параметрами работает намного быстрее. Имеется в виду, конечно же, вызов функции.

Имею опыт работы с одной из мировых грандов в ERP. система - объектная, каждому объекту соответсвует оракловский пакет, обычно со множеством функций. Так жее каждому объекту соответствует одно представление (как минимум одно). Так вот, большинство представлений включают в себя вызов пакетных функции. И, представьте себе, система - рекордсмен по производительности. То есть, реализация (в других системах) независимой от СУБД логики обычно только ухудшает производительность (я не касаюсь тут темы усложнения системы)...