Aleksey-K
1. По тексту запроса СНАЧАЛА строится оптимальный план запроса
2. Затем выбранный план запроса КОМПИЛИРУЕТСЯ.


Не совсем так. Что на эту тему пишут мэтры:

автор
Compilation
During the compilation process, SQL Server parses each statement and creates something called a sequence tree. This is one of the few data structures in SQL Server 2000 that has survived from SQL Server 6.5. The sequence tree is then normalized. The main function of the normalizer is to perform binding, which includes verifying that the tables and columns exist and loading the metadata for the tables and columns. Information about implicit conversions is also added to the sequence tree; for example, if the query is trying to add 10.0 to an integer value, SQL Server will insert an implicit convert into the tree. Normalization also replaces references to a view with the definition of that view. Finally, normalization includes a few syntax-based optimizations. If the statement is a DML statement, SQL Server extracts information from the sequence tree about that query and creates a special structure called a query graph, which is set up to let the optimizer work on it effectively. The query graph is then optimized and a plan is produced.

Kalen Delaney, Inside MS SQL Server 2000

По поводу курсоров. Честно говоря, не понимаю Вашего возмущения. Да, в профайлере присутствует вызов sp_cursoropen с последующими sp_cursorfetch, и что с того? Вы видели запрос, передаваемый в sp_cursoropen? К нему претензии есть? Нормальный запрос, необходимые условия WHERE, ORDER BY и GROUP BY присутствуют. Если раздражает вызов sp_cursorfetch при отборе следующей партии записей, посто настройте профайлер :)

Коллега, есть ощущение, что вы в вопросе разобрались не до конца. Само по себе использование prepared execution, кое вы наблюдаете в профайлере есть очень даже хорошо, тем более что эти подготовленные запросы (и планы исполнения, заметьте, тоже) могут быть использованы сервером приложений для разных клиентов.

Что касается использования (вернее, неиспользования) хранимых процедур. Да. Они не используются :) Встречный вопрос - Вы пробовали вести разработку приложения, работающего на нескольких разных СУБД (в данном случае - MSSQL и Oracle) ? И там бизнес-логика была в хранимых процедурах? И поведение системы на обоих СУБД было идентичным на 100%? И изменения в коде на одной в 100% случаев аккуратно и вовремя переносились на другую? Если на все предыдущий вопросы ответ "да" - снимаю шляпу.

А разработчики аксапты пошли другим путем. Они просто включили в язык, на котором написана бизнес-логика приложения, некоторое подмножество SQL. Да, этот SQL беднее и T-SQL? и PL/SQL. Зато приложение и код на обоих платформах одинаковые. А ядро обучено "переводить" X++ на понятный конкретной СУБД диалект, и делает это вполне пристойно.

P.S. На самом деле, когда я в первый раз заглянул в профайлер, испытал примерно те же чувства. Это проходит :)

Посмотрите на такие объекты, как Relations и DeleteActions (в AOD)
Не такие "железобетонные", как в случае, если бы они были определены на уровне СУБД, но работают, будучи правильно настроенными