Год назад, когда я работал еще с Sybase (Ак как известно Sybase и MSSQL - типа родственники), так вот там существовало такое понятие как "расщепление хранимой процедуры". Что это такое поясняю на пальцах. Кода ХП вызывается то ей указываются параметры. Чтобы построить эффективный план запроса оптимизатор должен знать параменты каждого запроса в ХП. А хранимка как известно состоит изк кучи запросов. Поэтому оптимизатор "расщепляет" ХП на запросы чтобы сформировать для каждого правильны план исзодя из данных параметров. Но, насколько я знаю те, кто пишет на T-SQL, частенько в ХП используют запросы которые используют временные таблицы созданные внутри процедуры, а также вычисляют параметры других запросов также динамически. Т.е. получается что в процесса построения плана запроса для ХП (до начала ее выполнения) оптимизатор не может правильно оценить мощность временной табицы, и значения динамических параметров запроса. Следовательно он не может построить эффективный план. (Я предкасно помню что на T-SQL некоторые ХП - это несколько страниц кода - увы это подавляющий стиль работы на T-SQL). Т.е. по идее чтобы написать хороший код на T-SQL следует делать 1 запрос на 1 ХП. Поэтому существуют системы в которых тысячи и десятки тысяч ХП. Честно говоря мне подобный стиль работы напоминает мусорную свалку. Назначение многих ХП просто забывается. А отказаться от использования ХП - это вообще очень-очень плохо - проверка синтаксива и компиляция во внутренний код всякий раз - это требует ресурсов.

Если посмотреть под такм же углом на DB2 - то после того как ХП откомпилирована - у нее уже есть план запроса. т.е. по сравнению с MSSQL где вы не увидите плана до тех пор пока не запустите процедуру в DB2 плпн уже есть - до выполнения. И он всегда один и тот же. (можно кстати, причем легко сделать так, чтобы менялся как и в MS, но я не сильно горю желанием использовать такую возможность). Т.е. добившись однажды нужного плана - вы можете отдыхать. Работа - сделана. А если кто-то будет утверждать, что в MS SQL можно добиться стабильности плана выполнения хинтами - то не верьте. Рано или поздно все равно нарветесь на проблемы.

Хух... устал писАть...

2 Yo!!
Дело ведь не только во временных таблицах, но и в динамически формируемых параметрах запросов. Типа:

вот в этом примере параметр @c1 - динамически вычисляемый, и следовательно план будет построен неоптимально.

2 Anton
Планы в DB2 строятся в момент связывания (операция BIND) в конкретной БД. И остаются постоянными пока кто-нить не грохнет какую-нить зависимость - типа почикают индекс, ну и естественно пакет станет невалидным и следующий раз при вызове пакета будет произведена попытка пересвязать пакет заново. Ну и в зависимости от результата - либо построится новый план либо облом.
Но план построится - и будет постоянным. И наплевать ему меняется ли статистика или нет. Т.е. вызвав db2expln.exe и посмотрев план - вы точно знаете что в пакете именно тот план, который вы видите. А в других базах это далеко не так. Оракл не исключение. Совсем не факт если вы даже выдите что запрос сейчас исполняется так как вам надо когда вы его тестируете, то легко может наступить помент когда это будет неверно.
Выгоды на самом деле в статическом SQL просто огромны, особенно в случае OLTP.ИМХО. Нелепо всякий раз пересматривать план простейшего запроса из 2-3 джойнов.
Мое мнение таково - статический SQL - это полезная фича. И единственная СУБД у кого это действительно есть - это ДБ2.

2 Yo!!
содержание таблиц, из мошность, отношение мощностей таблиц учавствующих в запросе действительно меняется постепенно. Но план запроса постепенно меняться не может. Он всегда ведь пересматривается полностью. Интересна ситуация когда запрос SELCT * FROM ... WHERE A1 LIKE="А%" в одном случае будет сканировать по диапазону индекса, а в друго выберет сканирование таблицы. Юзер надеется что в выборке все будет упорядочено по алфавиту. А результат в зависимости от параметра - разный то по алфавиту то вперемешку.