Почему это важно?

Любая учетная система решает три ключевые задачи: ввод, хранение и анализ данных. Т.е. анализ – это значительная доля от поставленных перед учетной системой задач. Что такое анализ для нас (как разработчиков)? – это запросы и отчеты.

Для пользователей отчеты – это ключевая функциональность. Если не будет отчетов – вся операционная деятельность в текущих реалиях будет парализована.

Мой почти 15- летний опыт работы в профессии показывает, что приходим мы в 1с не каким-то программированием заниматься. Мы приходим писать запросы и делать хорошие отчеты. 70-80% строчек написанного кода приходится как раз на них. И, раз это существенная доля нашей работы – делать ее нужно хорошо!

На вопрос, как правильно писать запросы – ответа нет. И, если кто-то вас будет убеждать в обратном – не верьте! А вот на вопрос, как правильно писать запросы для СКД, есть вполне хороший ответ.

В ЧЕМ ОТЛИЧИЕ ЗАПРОСА ДЛЯ СКД ОТ ОБЫЧНОГО ЗАПРОСА?

Для начала разберемся, почему запрос для СКД принципиально отличается от обычного запроса.

Все очень просто – запрос, помещенный в схему компоновки данных, НИКОГДА НЕ ВЫПОЛНЯЕТСЯ.

Если вы выполните запрос из общего модуля – платформа будет работать ровно с тем текстом запроса, который вы написали. А вот при формировании отчета, платформа всегда выполняет какой-то другой запрос. Какой?

ГДЕ ПОСМОТРЕТЬ ИСПОЛНЯЕМЫЙ (ПЛАТФОРМОЙ) ТЕКСТ ЗАПРОСА?

Что происходит при формировании отчета? Схема компоновки данных и Настройки компоновки данных передаются в Компоновщик макета компоновки данных. Компоновщик готовит нам макет компоновки – некую «сводную инструкцию» по формированию отчета, в которой в том числе будет текст исполняемого запроса. Далее «инструкция», а также, при желании, внешние наборы данных (и/или) менеджер временных таблиц передаются в процессор компоновки Процессор компоновки «передается» в процессор вывода. Процессор компоновки по запросу от процессора вывода формирует к БД запрос. На выходе - отчет (или данные). Еще не уснули?

(Как на такой «зубодробительной» терминологии можно нынешнее поколение стажеров, которые и слова-то такого страшного «Компоновка» не знают, обучать?!)

Что для нас ключевое? Наш текст запроса попадает вместе с различными настройками в компоновщик и что-то там с ним происходит. Давайте разбираться – что? И как этим управлять?

Какой запрос выполняется при формировании отчета?

Возьмем «идеальный» запрос – выберем парочку полей из справочника и «скормим» его СКД. Количество – это ресурс, суммируем.

Смотрите, какой интересный результат мы получим:

По сравнению с тем запросом, который мы написали, исполняемый платформой запрос как-то подозрительно «распух». А на уровне базы данных мы вообще получаем два левых соединения. Причем основная таблица, в которой хранятся данные справочника, соединяется сама с собой. Это тот результат, который вы ожидали?

Почему это произошло?

Во-первых, пользователю не нужны ссылки – ему нужны представления. Ссылка – это непонятный, нечитаемый набор символов.

Во-вторых, с неупорядоченной выборкой пользователю работать не удобно. Группировать логичнее упорядоченную выборку. Группировку (уже в смысле агрегирования) и сортировку выборки выгоднее выполнять средствами СУБД, а не платформы. (Это мнение разработчиков платформы, а не мое. Иначе бы мы не увидели картинку с «пухлым» исполняемым запросом).

Вот платформа и добавила нам в НАШ запрос упорядочивание и группировку выборки, и заодно вытянула поля представления.

Можно ли как-то этим управлять? Да, можно. Переопределив поля упорядочивания и представления (сортировка/группировка будут выполняться тогда платформой) и отключив галку «Использовать группировки запроса, если возможно». В таком случае будет выполнятся платформой ровно тот запрос, который вы напишете. (Так он все-таки иногда выполняется? Или нет?)

Если вы сейчас решили, что я призываю вас переопределять поля представления/ упорядочивания -  вы не правы. НЕ ВЗДУМАЙТЕ это делать!

Во-первых, если сортировка/группировка будут выполняться платформой, а не СУБД, вы можете на самом деле получить деградацию в скорости.

Во-вторых, MS SQL отлично «вытягивает» подобные запросы. И даже, если вы сделали по тексту запроса соединение с какой-то таблицей, из которой можно выбрать сразу и поле представления, «накладные расходы» на то, чтобы «протащить» его через «десяток» временных таблиц, могут оказаться больше, чем «расходы» на левое соединение в последнем запросе пакета. Для PostgreSQL иногда это может привести к выигрышу по скорости, но с каждым запросом нужно разбираться индивидуально.

В-третьих, разработчики платформы- далеко не глупые люди, и лучше нас понимают проблематику. Например, если для поля составного типа нужно получить представление, скорее всего платформа сформирует отдельные запросы для массива ссылок к разным таблицам, а не сделает левое соединение с безумным количеством таблиц в запросе. А вот разработчик 1С может принудительно это «безумное» соединение создать. А потом сидеть и удивляться, «а чего отчет не формируется?»

Короче, развлекаться с переопределением стоит лишь, когда скорость выполнения последнего запроса пакета неудовлетворительная и крайне осторожно.

ВСЕ, ЧТО ВЫ ДОЛЖНЫ ИЗВЛЕЧЬ ДЛЯ СЕБЯ ИЗ ДАННОГО ПРИМЕРА – БЕСПОЛЕЗНО ОТЛАЖИВАТЬ В КОНСОЛИ ЗАПРОСОВ ИСХОДНЫЙ ЗАПРОС! ЗАЧЕМ ОТЛАЖИВАТЬ ТО, ЧТО НЕ ВЫПОЛНЯЕТСЯ?

ПРОБЛЕМА МИНИМИЗАЦИИ ВЫБОРКИ

Какие у нас есть общие правила по созданию запросов?

«Нужно стараться минимизировать объем выборки, то есть выбирать запросом только те данные, которые нужны». (цитата с сайта ИТС).

НО. Отчет в себе подразумевает возможность гибкой настройки. Пользователь может удалить или добавить какие-то поля. Может установить отборы. Значит, независимо от настроек, исполняемый при формировании отчета, запрос должен минимизировать объемы выборки.

Давайте введем определение:

«Хороший» запрос для СКД – это запрос, который независимо от настроек формирует минимально необходимые для вывода в отчет выборки. (Естественно, с учетом ограничений заложенных самой структурой запроса.)

(При отсутствии официальной терминологии от вендора мы имеем право вводить любую.)

Что такое выборка? Как вы ее у себя в голове представляете? Скорее всего, как таблицу. Таблица - это «пересечение строк и колонок». Как можно уменьшить объем таблицы? Удалить из нее лишние «колонки» и/или «строки». Начнем с «колонок».

УДАЛЕНИЕ НЕНУЖНЫХ ПОЛЕЙ ИЗ ТЕКСТА ЗАПРОСА

Компоновщик макета старается удалить все ненужные «колонки» из текста запроса. Если пользователь не запросил на вывод какие-то поля – он старается от них избавиться.

Исключения:

• Обязательные поля (всегда доходят до финиша)
• Поля, на которые установлен жесткий отбор
• Поля, участвующие в условиях соединения

Логика, примерно, следующая:

Очень частая ошибка при написании запросов для СКД– поле группировки не выведено в отчет. Любой расчет, завязанный на присутствие поля в выборке – приведет к ошибке.

Какие это дает возможности при написании запроса?

МОЖНО выбрать что-нибудь полезное «про запас» для пользователя. В запросе для СКД мы не обременены жестким правилом «минимизации выборки». Компоновщик все невостребованное сам из текста запроса удалит.

МОЖНО выбрать что-нибудь полезное для себя (чем мы хуже пользователя?):

• • Очень важную информацию, которую должен прочитать разработчик.
  • Комментарии по логике построения запроса.
  • Поля для разметки текста запроса.

С чем нужно быть осторожным, когда выбираем что-нибудь «полезное» –так это с последним запросом в пакете (если галку «автозаполнение» сняли). Алгоритм оптимизации текста запроса явно анализирует список полей набора схемы КД (это то, что над запросом). Если выбранное в последнем запросе поле не попадет в поля набора схемы КД – оптимизация текста запроса (только последнего запроса в пакете) не случится.

А еще компоновщик игнорирует вложенные запросы! Совсем-совсем!

Уперлись, видимо, разработчики компоновщика в не уникальность круглых скобок (обрамляющих вложенный запрос) в тексте запроса. Были бы они квадратные – оптимизация, вероятно, давно бы состоялась (навскидку, поместить текст вложенного запроса во временную таблицу выше, применить алгоритм оптимизации и вернуть обратно – технически, вполне, возможно. Даже с учетом «многоуровнести» вложенности запросов). НО! Нерешаемых задач, ведь, нет! Может, пора уже эту задачу решить?

Или алгоритм компоновщика появился в платформе раньше, чем вложенные запросы. И живет по принципу: «работает – не трогай»!

УДАЛЕНИЕ НЕНУЖНЫХ ТАБЛИЦ И СОЕДИНЕНИЙ

Компоновщик может сам удалить из запроса ненужные временные таблицы, если с ними отсутствуют соединения или объединения.

Во всех остальных случаях компоновщику нужно помочь – оставить инструкции, какие соединения между таблицами являются необязательными.

По умолчанию, если мы сделали обязательное соединение в запросе и не вывели поля из правого набора в отчет – мы получим следующую картину:

Но, если мы сделаем соединение «необязательным» (за это отвечают фигурные скобочки) - временная таблица из текста запроса будет полностью исключена:

Работает алгоритм исключения ненужных таблиц из текста запроса примерно по следующей логике:

Нам же это дает преимущество: в один запрос можно заложить сбор данных для разных вариантов отчета (кратких и расширенных). Запрос всегда будет «хороший»! Не плодите десятки одинаковых форм – сделайте одну. Одну сопровождать проще!

«МИНИМИЗАЦИЯ СТРОК». ПОЛЬЗОВАТЕЛЬСКИЕ ОТБОРЫ

Если пользователь установит в отчете отбор по какому-либо полю, компоновщик постарается в исходный текст запроса подставить условие «ГДЕ» на это поле (или параметризовать виртуальную таблицу). Пример корректной автоматической расстановки условий:

Но, стоит нам немного пошалить (переименуем поле) - и алгоритм начинает сбоить:

Что можно путем эксперимента выяснить про алгоритм расстановки условий:

• Расстановка условий выполняется до удаления полей (в т.ч. для необязательных таблиц).
• Алгоритм анализирует только временные таблицы и виды соединений (левое/внутреннее) между ними.
• Во временных таблицах алгоритм анализирует только наличие поля, имя которого (после как) соответствует полю, на которое установлен отбор.
• Алгоритм, м.б. как-то анализирует метаданные, т.к. параметризация виртуальных таблиц выполняется только, если имя измерения совпало с именем поля отбора. И принудительно пытается параметризовать виртуальную таблицу, даже если измерение не выбрано в тексте запроса.
• После левого соединения, если поле выбрано из правого набора, устанавливается повторный отбор.

• АЛГОРИТМ НЕ АНАЛИЗИРУЕТ условия соединение между временными таблицами и не анализирует «трансформации» поля по тексту запроса.
• Вложенные запросы игнорируются.

Скорее всего алгоритм работает примерно следующим образом («исходники», естественно, я не видела -могу только предполагать. Но противоречий с описанной логикой пока не выявила, и, на 90% уверена, что работает он примерно так).

Из временных таблиц составляется «пусть будет дерево» («новобранцы» - выпускники ВУЗов, что это за структура данных и как называется алгоритм обхода?), где корнем является последний запрос в пакете, а листьями - временные таблицы, в которых нет выборки данных из других временных таблиц. В узлах этого «дерева» сливаются в левых и внутренних соединениях временные таблицы (и/или/не выбираются доп. данные из БД), стремясь «объединиться в единое целое» в последнем запросе пакета. Выстраиваются все цепочки «слияний» временных таблиц от листьев до корня. Циклов здесь быть не может (ВТ не может являться источником данных для самой себя). Вероятно, рассчитывается для каждого узла максимальная длина пути до корня, и в порядке убывания этой величины выполняется обход. (Объединения в запросах, вероятно, разбиваются на отдельные узлы и сливаются в один вспомогательный).

• Если в узле есть поле (с нужным наименованием), и нет отбора в поддеревьях –устанавливается отбор.
• Если в узле внутреннее соединение между ВТ– и есть отбор в поддеревьях (соответствующих этим ВТ) – отбор не нужен.
• Если в узле левое соединение тогда:
  • Если в поддереве, соответствующем, правому набору был отбор, а в соответствующем левому отсутствует – устанавливается дополнительный отбор (на поле правого набора).
  • Если в поддереве, соответствующему левому набору – был, то отбор не устанавливается.

Главное здесь:

• не выполняется анализ, выбрано ли поле из БД;
• не анализируются условия соединений;
• не анализируется – пропадало ли поле/ появлялось/ переименовывалось/ переопределялось.

Ключевое для алгоритма – был ли в поддеревьях отбор.

Следовательно, для того, чтобы алгоритм работал корректно:

• Если поле присутствует в последнем тексте запроса, то от любой временной таблицы, в которой это поле появилось, оно должно без переименований и модификаций (исключение – проверка на ЕстьNull) «дойти до финиша». Или пропасть (из правого набора) в условии соединения. (Пропадать и вновь появляться от листьев к корню по цепочке ВТ оно не должно). Вводить по тексту запроса разные «сущности» с одинаковым наименованием (с целью позднее переименовать) также запрещено.

Переименования полей по тексту запроса приводят к некорректной работе алгоритма.

Переопределение полей тоже:

• При левом соединении поле не может быть выбрано из правого набора, отсутствовать в условии соединения, и присутствовать в левом наборе. (Вообще - это логическая ошибка построения запроса).

• Переименовывать при выборке из виртуальных таблиц измерения – запрещено.

• Если по каким-то причинам отбор на уровне временной таблицы не должен сработать – необходимо принудительно переименовать поле. (уникальное наименование, не встречающееся по тексту запроса). И в нужном месте переименовать «обратно». 

• Для виртуальных таблиц срабатывает принудительная параметризация на не выбранное измерение, если его имя совпадает с именем поля, на которое установлен отбор. Т.е. названия выбираемых по тексту запроса ниже полей не должны совпадать с именами не выбранных измерений виртуальной таблицы. (И если у нас две виртуальные таблицы с одинаковыми названиями измерений, в одной из которых нужен отбор, а во второй нет - заходим в тупик).
• 

• Выбирать данные из БД во вложенных запросах запрещено. Причем смотрите, как интересно - с установкой отбора после левого соединения ВТ во вложенных запросах , алгоритм все-таки справляется: 

ПРОБЛЕМА УСТАНОВКИ ОТБОРОВ НА РЕСУРСЫ

Давайте сразу уточним – под «ресурсами» понимаем только количественные и суммовые поля. Если вы, вдруг, группируете даты в массив или делаете конкатенацию строк – для нас это не ресурсы, а аналитики (которые пользователю зачем-то в одной ячейке нужны).

Проблема с ресурсами в том, что отбор на них почти всегда работает некорректно, если взглянуть на это глазами пользователя. Пользователь меняет состав полей в отчете, устанавливает отбор и ожидает, что он будет применен к итоговой сумме по группировке. Лезть в настройки для разработчика и устанавливать там отборы на уровне группировки – это слишком сложно и непонятно.

Для установки отборов по ресурсам, срабатывает точно такая же логика, как и для всех остальных полей – отбор накладывается в первом (по «дереву» ВТ) месте появления поля в запросе (и после левых соединений вт на поля правых наборов). С учетом удаления лишних полей в зависимости от пользовательской настройки – к чему этот отбор будет применен, предугадать невозможно.

Даже, если «отключить» принудительно установку отбора до последнего запроса в пакете, то все равно отбор будет некорректным – он не к агрегированному значению применяется, а просто к выбранному полю.

Задачу можно решить принудительным суммированием (с отключением промежуточного отбора) в последнем запросе пакета:

Тогда отбор все-таки будет применен к агрегированному значению (но если будут обязательные поля, не выведенные в отчет - все-равно будет работать некорректно). А еще, не поверите – проблема решается просто запретом установки отборов на ресурсы. Или запретом редактирования структуры отчета. Так тоже МОЖНО.

ПРОЧИЕ МОДИФИКАЦИИ ТЕКСТА ЗАПРОСА

Чаще всего галку «Автозаполнение» разработчика заставляет снимать некорректная параметризация виртуальных таблиц по периоду. Независимо от того, прописаны ли параметры-периоды в запросе, принудительно добавляются параметры с определенными наименованиями в параметры схемы компоновки. И, если вдруг эти параметры будут установлены – компоновщик пропишет их в текст исполняемого запроса.

Проблема возникнет, например, если:

• Срезы последних/обороты нужны на/за разные периоды в одном запросе.
• Если хотим и обороты, и срез последних в одном запросе.
• Если нужен запрос к таблице итогов регистра сведений (для этого параметризации по периоду не нужна).

А если автоматически добавленному параметру «Период» (для среза последних) тип переопределить на «стандартный период» - отчет вообще формироваться не будет.

«РАЗМЫШЛИЗМЫ»

Вы можете все, что я выше описала, при создании запроса для СКД в голове удержать (и, естественно, соблюсти)?...  Заниматься переименованиями полей, только для того, чтобы отбор не сработал – звучит бредово. Плюс еще и ограничение на выборку из БД во вложенных запросах.

Гадать – угадает ли компоновщик с расстановкой отборов по тексту запроса - не хочется. 

Документации нормальной по данному вопросу от фирмы 1С у нас нет. Вообще никакой нет((( 

(Вот, кстати, больная тема, а по какому вопросу она у нас вообще есть? Фирма 1С мается - не знает, как квалифицированные кадры получить. Внедряют систему наставничества, ИИ активно рекламируют, чтобы он нам стажеров (?м)учил (ну вот как можно «неокрепшим молодым умам» давать игрушку, которая на одинаковом коде различные рекомендации выдает?!!).

Я знаю ответ на этот вопрос. ДОКУМЕНТАЦИЮ НОРМАЛЬНУЮ НУЖНО НАПИСАТЬ! ЕМКУЮ И ЧИТАЕМУЮ! Без «перлов» на подобии «управляемой формы, единой в двух ипостасях &НаКлиенте и &НаСервере». И без "зубодробительного" компоновщика макета компоновки данных. Пока документации не будет – квалифицированных специалистов ждать бесполезно!)

Какой из этого всего вывод? Контролируем процесс самостоятельно! Тем более, что все возможности у нас для этого есть.

ИНСТРУКЦИИ КОМПОНОВЩИКУ. СНИМАЕМ ГАЛКУ

Нам доступны три вида инструкций компоновщику. Две из них позволяют управлять модификациями текста запроса. (третья – только через ошибку, когда ненужные поля не удаляются из текста последнего запроса). Доступны они на закладке «Компоновка данных».

(Абсолютно дурацкое, кстати, название! Предлагаю переименовать в «Оптимизация». Слово модное, привлекательное –сразу и интерес у разработчиков появится (и букв в слове меньше)! Чувствуете, как красиво с правильно подобранным названием смыслы смещаются?)

• Необязательные соединения между таблицами. Уже разобрали выше. Не хотите ставить скобки в тексте запроса – снимайте галки. Единственное, что стоит дополнить – все, что в скобках (а там может быть несколько таблиц) удаляется по принципу «все или ничего».
• Формирование списка полей набора схемы компоновки данных доступных для вывода.
• «Нежесткая» параметризация (одновременно и инструкция для формирования полей набора схемы, доступных для отбора).

Инструкции по формированию полей набора схемы (доступных для вывода)

Немного остановимся на втором виде инструкций. Опытным путем выявлено, что:

• Поля формируются (при снятой галке) только по инструкциям последнего запроса пакета.

• Не влияют на модификацию запроса, если пользователь в отчет выведет какие-то реквизиты доступных полей (через «.») Все что через «.» попадет безусловно в последний запрос пакета. Если у вас поля составного типа или очень большие таблицы – запрещайте выбор реквизитов. (И даже так МОЖНО!)

• Могут запутать компоновщик. (Этот результат получен при установленной галке).

ВЫВОД. Должны находиться только в последнем запросе пакета.

Инструкции для подстановки условий в текст запроса (нежесткой параметризации)

Тут тоже все просто. Можно указать компоновщику:

• Подставить условие на поле отбора в запрос в секцию «ГДЕ»
• Подставить условие на поле отбора в параметры виртуальной таблицы.
• Подставить условие (или параметр-период виртуальной таблицы), если пользователь заполнил необязательный параметр. С полями так, кстати, не получится (подставить отбор на поле, если пользователь вывел это поле в отчет).

(Вот, кстати, а что помешало разработчикам платформы при снятии галки автоматически инструкции в текст запроса добавлять? Алгоритм же есть! Заглушку от плохих запросов к БД в виде галки сделали, а вот от не очень умного разработчика 1с, который эту галку может снять –нет. Нелогично. Снова ограничения синтаксиса?)

ИНСТРУКЦИИ VS АЛГОРИТМ

А что будет, если одновременно оставить галку и указать инструкции?

Если условие установить ниже по тексту запроса, чем место, которое рассчитает алгоритм компоновщика -  отбор будет подставлен и по инструкции, и по алгоритму.

А вот если выше – то только по инструкции. Из чего можно сделать вывод, что сначала расставляются («по дереву ВТ») отборы по инструкциям, а потом вызывается алгоритм «обхода дерева», который их в т.ч. учитывает.

Причем, похоже, общая схема следующая:

• Расстановка отборов по инструкциям
• Расстановка отборов по алгоритму (если не сняли галку) 
• Удаление ненужных полей
• Удаление ненужных таблиц (временные таблицы без соединений (ошибочно оставленные), вероятно, удаляются сразу, в момент построения дерева)

Переубедить, кстати, компоновщик НЕ размещать условие «где» в тексте запроса с помощью инструкций за счет переопределения псевдонима тоже не получится. А вот отключить параметризацию виртуальных таблиц поможет :

«Базовый рецепт» расстановки инструкций для компоновщика

Нам сейчас абсолютно не важно, какой у нас написан запрос (плохой/ хороший/ оптимальный/ неоптимальный…). Наша задача – превратить его в «хороший» для СКД. Сделать это можно следующим образом:

• Делим все выбираемые поля на «аналитики» и «ресурсы». «Ресурсы» – это только суммовые и количественные поля, к которым будем применять агрегатные функции. Все, что не «ресурсы» – это «аналитики».
• Если поле - «аналитика» выбирается из БД (в т.ч. через «.» от ссылки) и отсутствует жесткая параметризация на это поле– обязательно устанавливается «нежесткая» параметризация.
• Если поле «приходит» за счет внутреннего соединения между временными таблицами – параметризация не нужна. (Естественно, на все новое - расчетное или вытаскиваемое из таблиц БД - инструкция.)
• Если поле «приходит» за счет левого соединения между временными таблицами – дополнительная параметризация на поле из правой таблицы (с проверкой на ЕстьNull).
• Ко всем «ресурсам» – нежесткая параметризация на уровне последнего запроса в пакете (с обязательным применением агрегатных функций). Или вообще отборы не разрешать устанавливать.

Когда «базовый рецепт» не работает?

• Когда одна и та же выборка будет анализироваться в разных аналитических разрезах, т.е. отбор «максимально рано» не нужен.
• Когда не уследим за переименованиями/переопределениями.

НО! В чем «прелесть»? Если инструкции расставлены некорректно – это сразу выявится при тестировании/ в процессе эксплуатации. А если не оставлены (например, «плюхнуты» на уровень последнего запроса пакета) – этого никто никогда не найдет и править не будет!.

В чем смысл? Компоновщик же по «базовому рецепту» и работает?

Если вы вдумчиво читали, то у вас сейчас должен резонно возникнуть вопрос. Ответ – ДА! Я предлагаю вам вручную делать примерно ту же работу, которую выполняет компоновщик.

Почему?

Во-первых, когда рецепт «засбоит», а он обязательно «засбоит» – все инструкции по тексту запроса у вас уже будут расставлены. Вам останется их только «опустить» немного ниже по тексту запроса. И вы не получите ситуацию, когда не очень умный разработчик снимет галку и все инструкции на «нежесткие» оборы оставит в последнем запросе пакета!

Во–вторых, компоновщик не может определить, будут ли выбираться данные из БД, он может только на имя поля ориентироваться. А вот вы –да.

В-третьих, когда вы, осознанно, в каждой временной таблице задаете вопрос: «должно ли в этом запросе подставиться условие, если пользователь установит отбор на поле с этим (или оно д.б. не этим?) наименованием – вероятность ошибки на переименованиях/переопределениях/досрочных параметризациях снижается.

В-четвертых, мы даем абсолютно убогие наименования объектам метаданных. Любой, оставленный нами код контекстен. О чем вы думали полгода назад, когда какой-то реквизит наименовывали – тайна, покрытая мраком. Так что переименований не избежать!

В–пятых, вложенные запросы - это отличная функциональность! Иногда за счет избавления от временных таблиц можно очень хорошего ускорения добиться.

И, напоследок - это прекрасное упражнение для мозга. Причем совершенно бесплатно!

Чек-лист.

Перед началом работы.

1. Вспомнить, что пишете не запрос, а запрос для СКД. Ваш запрос формироваться не будет, а будет формироваться бесконечное множество каких-то других. И все они д.б. «хорошие»!

До открытия конструктора запроса.

2. Создать отчет в конфигураторе! Никогда не может создание запроса для СКД начинаться с консоли запросов в пользовательском режиме!
3. Переопределить метод «ПриКомпоновкеДанных».
4. Снять галку «Автозаполнение». (Если в пакетном запросе будет хотя бы одна временная таблица). Пусть вас утешает мысль, что вы умнее алгоритма.

Пишем запрос

5. Написать запрос. Расставить инструкции. Создали временную таблицу/вложенный запрос – СРАЗУ заполнили «нежесткие отборы» по "базовому рецепту". Над каждым выбранным полем в каждой временной таблице размышляем, должен ли сработать отбор. (Ну или напишите себе обработку, которая инструкции за вас расставит. Разработчики вы, или кто?)
6. Оставить комментарии для «потомков». Чтобы потом не страдать, вспоминая, что в своем же собственном запросе сотворили.

Проверки

7. Проверить, что для всех полей последнего запроса есть инструкции на формирование полей набора схемы (доступных для вывода). Проверить, что во временных таблицах нет инструкций.

8.  Проверить, что все инструкции для параметризации запроса оставлены:

• Есть выборка из БД и нет нежесткой (или жесткой) параметризации по выбранным полям. Ответить почему.
• Есть выборка из временной таблицы, к которой делается левое соединение. Проверить наличие инструкций на поля из правого набора с проверкой на ЕстьNULL.
• Проверить расшифровки. Все поля исходной группировки должны попасть в отбор.

9. Проверить, что не было переименований полей (до «как» и после). Если были – перепроверить инструкции компоновщику.

10. Проверить поля наборы схемы на «странные» наименования. Уделить внимание полям, доступным только для отбора. Если есть – перепроверить инструкции.

11. Проверить текст запроса на наличие конструкции «Сгруппировать» и «Различные». Можно для проверки удалить поля группировки из выводимых полей. Если результат некорректный – сделать поля обязательными.
12. Проверить соединения между таблицами. Ответить на вопрос, точно ли должны быть обязательными?
13. Проверить запрос на наличие вложенных. Вспомнить, что алгоритм оптимизации не справляется с удалением невостребованных полей из вложенных запросов. (Не должно быть в них много "полезного" про запас.)
14. Проверить периодичность виртуальных таблиц оборотов РН. Не должно быть меньше месяца. В идеале – д.б. «АВТО» или «Период».

Не может платформа ничего «оптимизировать» (опять проблема отсутствия нормальной документации), если периодичность меньше месяца –это детерминировано логикой хранения данных в БД в двух таблицах (в одной общие суммы за месяц, в другой – все данные). Платформа только «сгруппировать» (это разве оптимизация?) в текст запроса по таблице движений сможет добавить – с этим вы способны справиться самостоятельно. Не занимайтесь самообманом – пишите запрос к основной таблице, чтобы не получалась такая «красота» в виде соединения таблицы оборотов с основной таблицей ради реквизитов.

Отладка

14. Отлаживать ТОЛЬКО исполняемый запрос. Все правки вносить только в конфигураторе.

На этом наше исследование подошло к концу. Пишите запросы для СКД правильно! 

P.S. Так он все-таки иногда выполняется? Или все-таки нет?

P.S.2 Мне кажется, мой труд заслуживает спасибо, даже, если где-то были допущены неточности. (Если найдете - пишите. Поправим.) Как минимум потому, что редактор текста на данном сайте очень похож на инструмент для пыток. Гадости, «испражнения» и не объединенные общим смыслом наборы букв оставляйте, пожалуйста, при себе. Оно мне не надо. Претензии по качеству скриншотов – напрямую разработчикам сайта.

P.S.3 Ну и, конечно, ЛЮБИТЕ СКД ТАК, КАК ЛЮБЛЮ ЕЕ Я! И ДОЛОЙ СТЕРЕОТИПЫ – СВОБОДУ МЫСЛИ!