:-\\ serge_b77 :-\\
Т.к. подобного рода "перлы" ... написал (и вставил в конфу) такой же "прикладной программист" как и все здесь присутствующие.

Что же в этом плохого?Конфигурации и платформа и образуют единое решение.Поэтому и оптимизация запроса ,продуманная программистом,ничем не хуже "автоматической" оптимизации,которая должна по-Вашему,выполняться на сервере.Сколько лет ждали этого от 1С!
Теперь дождались - и снова вопли непонимания.

"Плохого" в этом прежде всего то, что т.н. "платформа" с ее т.н. "сервером приложений" строго ограничивают реального разработчика прикладных решений на основе этой же платфомы тем куцым набором "усекновенных" инструментов, что может себе позволить недо-реализовать команда разработчиков фирмы 1С.
Зачем, скажите на милость, делать русскоязычный клон SQL (с SELECT и JOIN, но без INSERT/UPDATE)? Зачем делать свой собственный "объектно-событийный" скриптовый язык (с try и cath/except, но без finally)? А также - повторять функциональность подавляющего большинства системных ActiveX (FTP, HTTP, SMTP, XML и т.д.), опять же не без "усекновения" их уже "готовой" функциональности?
Я лично не понимаю...
Что касается "оптимизации запроса ,продуманной программистом" - на встроенном 1СQL вы не особо много "наоптимизируете", т.к. т.н. "сервер приложений" при переводе вашего запроса на реальный запрос к СУРБД добавит такой "отсебятины", что никакая "автоматическая" оптимизация не поможет...
Тут немного выше один гражданин хвастался тем, что при выводе списка на экране 1С запрашивает не все данные из таблицы, а только те, которые необходимо показать. Я не поленился запустить профайлер и посмотреть - что же там на самом деле спрашивается у СУРБД при выводе "без иерархии" справочника номенклатур (у всех такой есть, в любой стандартной и нестандартной конфигурации).
Увиденное повергло в печаль: "SELECT TOP 45 ... FROM _ReferenceXXX (LEFT OUTER JOIN _ReferenceYYY ON ... (5 раз)) WHERE _ReferenceXXX._IdRRef > 0xBLAHBLAHBLAH OR _ReferenceXXX._Description > 'BLAH-BLAH-BLAH' ".
Что толку клиенту от того, что он ждет свои несчастные 45 записей от сервера, который при этом сканирует полное объединение по минимум 5-ти не самым маленьким таблицам в режиме сравнения текстовых строк по наименованиям номенклатур.
Да за такую "эффективность" запросов к серверу любого нормального SQL-программиста давно бы уже распяли на общем собрании коллектива и вправили мозги в "нужную сторону".
А франчам все похрену - они железо советуют наращивать... благо: "гигабайты нынче дешевы".
А можно еще убрать лишние записи из таблиц, связанных со справочником номенклатуры.
Глядишь и запрос будет быстрее выполнятся.