Как правильно писать запросы для СКД. Фундаментальное исследование
Почему это важно?
Любая учетная система решает три ключевые задачи: ввод, хранение и анализ данных. Т.е. анализ – это значительная доля от поставленных перед учетной системой задач. Что такое анализ для нас (как разработчиков)? – это запросы и отчеты.
Для пользователей отчеты – это ключевая функциональность. Если не будет отчетов – вся операционная деятельность в текущих реалиях будет парализована.
Мой почти 15- летний опыт работы в профессии показывает, что приходим мы в 1с не каким-то программированием заниматься. Мы приходим писать запросы и делать хорошие отчеты. 70-80% строчек написанного кода приходится как раз на них. И, раз это существенная доля нашей работы – делать ее нужно хорошо!
На вопрос, как правильно писать запросы – ответа нет. И, если кто-то вас будет убеждать в обратном – не верьте! А вот на вопрос, как правильно писать запросы для СКД, есть вполне хороший ответ.
В ЧЕМ ОТЛИЧИЕ ЗАПРОСА ДЛЯ СКД ОТ ОБЫЧНОГО ЗАПРОСА?
Для начала разберемся, почему запрос для СКД принципиально отличается от обычного запроса.
Все очень просто – запрос, помещенный в схему компоновки данных, НИКОГДА НЕ ВЫПОЛНЯЕТСЯ.
(Уточним (здесь и далее). Имеется в виду, что платформа при формировании отчета никогда не выполняет запрос с тем текстом, который написал разработчик. Текст исполняемого запроса всегда будет отличаться. И, перед тем, как доказывать обратное, дочитайте, все-таки, статью до конца.)
Если вы выполните запрос из общего модуля – платформа будет работать ровно с тем текстом запроса, который вы написали. А вот при формировании отчета, платформа всегда выполняет какой-то другой запрос. Какой?
ГДЕ ПОСМОТРЕТЬ ИСПОЛНЯЕМЫЙ (ПЛАТФОРМОЙ) ТЕКСТ ЗАПРОСА?
Что происходит при формировании отчета? Схема компоновки данных и Настройки компоновки данных передаются в Компоновщик макета компоновки данных. Компоновщик готовит нам макет компоновки – некую «сводную инструкцию» по формированию отчета, в которой в том числе будет текст исполняемого запроса. Далее «инструкция», а также, при желании, внешние наборы данных (и/или) менеджер временных таблиц передаются в процессор компоновки Процессор компоновки «передается» в процессор вывода. Процессор компоновки по запросу от процессора вывода формирует к БД запрос. На выходе - отчет (или данные). Еще не уснули?
(Как на такой «зубодробительной» терминологии можно нынешнее поколение стажеров, которые и слова-то такого страшного «Компоновка» не знают, обучать?!)
Что для нас ключевое? Наш текст запроса попадает вместе с различными настройками в компоновщик и что-то там с ним происходит. Давайте разбираться – что? И как этим управлять?
Какой запрос выполняется при формировании отчета?
Возьмем «идеальный» запрос – выберем парочку полей из справочника и «скормим» его СКД. Количество – это ресурс, суммируем.
Смотрите, какой интересный результат мы получим:
По сравнению с тем запросом, который мы написали, исполняемый платформой запрос как-то подозрительно «распух». А на уровне базы данных мы вообще получаем два левых соединения. Причем основная таблица, в которой хранятся данные справочника, соединяется сама с собой. Это тот результат, который вы ожидали?
Почему это произошло?
Во-первых, пользователю не нужны ссылки – ему нужны представления. Ссылка – это непонятный, нечитаемый набор символов.
Во-вторых, с неупорядоченной выборкой пользователю работать не удобно. Группировать логичнее упорядоченную выборку. Группировку (уже в смысле агрегирования) и сортировку выборки выгоднее выполнять средствами СУБД, а не платформы. (Это мнение разработчиков платформы, а не мое. Иначе бы мы не увидели картинку с «пухлым» исполняемым запросом).
Вот платформа и добавила нам в НАШ запрос упорядочивание и группировку выборки, и заодно вытянула поля представления.
Можно ли как-то этим управлять? Да, можно. Переопределив поля упорядочивания и представления (сортировка/группировка будут выполняться тогда платформой) и отключив галку «Использовать группировки запроса, если возможно». В таком случае будет выполнятся платформой ровно тот запрос, который вы напишете. (Так он все-таки иногда выполняется? Или нет?)
Если вы сейчас решили, что я призываю вас переопределять поля представления/ упорядочивания - вы не правы. НЕ ВЗДУМАЙТЕ это делать!
Во-первых, если сортировка/группировка будут выполняться платформой, а не СУБД, вы можете на самом деле получить деградацию в скорости.
Во-вторых, MS SQL отлично «вытягивает» подобные запросы. И даже, если вы сделали по тексту запроса соединение с какой-то таблицей, из которой можно выбрать сразу и поле представления, «накладные расходы» на то, чтобы «протащить» его через «десяток» временных таблиц, могут оказаться больше, чем «расходы» на левое соединение в последнем запросе пакета. Для PostgreSQL иногда это может привести к выигрышу по скорости, но с каждым запросом нужно разбираться индивидуально.
В-третьих, разработчики платформы- далеко не глупые люди, и лучше нас понимают проблематику. Например, если для поля составного типа нужно получить представление, скорее всего платформа сформирует отдельные запросы для массива ссылок к разным таблицам, а не сделает левое соединение с безумным количеством таблиц в запросе. А вот разработчик 1С может принудительно это «безумное» соединение создать. А потом сидеть и удивляться, «а чего отчет не формируется?»
Короче, развлекаться с переопределением стоит лишь, когда скорость выполнения последнего запроса пакета неудовлетворительная и крайне осторожно.
ВСЕ, ЧТО ВЫ ДОЛЖНЫ ИЗВЛЕЧЬ ДЛЯ СЕБЯ ИЗ ДАННОГО ПРИМЕРА – БЕСПОЛЕЗНО ОТЛАЖИВАТЬ В КОНСОЛИ ЗАПРОСОВ ИСХОДНЫЙ ЗАПРОС! ЗАЧЕМ ОТЛАЖИВАТЬ ТО, ЧТО НЕ ВЫПОЛНЯЕТСЯ?
ПРОБЛЕМА МИНИМИЗАЦИИ ВЫБОРКИ
Какие у нас есть общие правила по созданию запросов?
«Нужно стараться минимизировать объем выборки, то есть выбирать запросом только те данные, которые нужны». (цитата с сайта ИТС).
НО. Отчет в себе подразумевает возможность гибкой настройки. Пользователь может удалить или добавить какие-то поля. Может установить отборы. Значит, независимо от настроек, исполняемый при формировании отчета, запрос должен минимизировать объемы выборки.
Давайте введем определение:
«Хороший» запрос для СКД – это запрос, который независимо от настроек формирует минимально необходимые для вывода в отчет выборки. (Естественно, с учетом ограничений заложенных самой структурой запроса.)
(При отсутствии официальной терминологии от вендора - мы имеем право вводить любую.)
Что такое выборка? Как вы ее у себя в голове представляете? Скорее всего, как таблицу. Таблица - это «пересечение строк и колонок». Как можно уменьшить объем таблицы? Удалить из нее лишние «колонки» и/или «строки». Начнем с «колонок».
УДАЛЕНИЕ НЕНУЖНЫХ ПОЛЕЙ ИЗ ТЕКСТА ЗАПРОСА
Компоновщик макета старается удалить все ненужные «колонки» из текста запроса. Если пользователь не запросил на вывод какие-то поля – он старается от них избавиться.
Исключения:
- Обязательные поля (всегда доходят до финиша)
- Поля, на которые установлен жесткий отбор
- Поля, участвующие в условиях соединения
Логика, примерно, следующая:
Очень частая ошибка при написании запросов для СКД– поле группировки не выведено в отчет. Любой расчет, завязанный на присутствие поля в выборке – приведет к "ошибке" (к результату, не соответствующему первоначальной постановке).
Какие это дает возможности при написании запроса?
МОЖНО выбрать что-нибудь полезное «про запас» для пользователя. В запросе для СКД мы не обременены жестким правилом «минимизации выборки». Компоновщик все невостребованное сам из текста запроса удалит.
МОЖНО выбрать что-нибудь полезное для себя (чем мы хуже пользователя?):
-
- Очень важную информацию, которую должен прочитать разработчик.
- Комментарии по логике построения запроса.
- Поля для разметки текста запроса.
С чем нужно быть осторожным, когда выбираем что-нибудь «полезное» –так это с последним запросом в пакете (если галку «автозаполнение» сняли). Алгоритм оптимизации текста запроса явно анализирует список полей набора схемы КД (это то, что над запросом). Если выбранное в последнем запросе поле не попадет в поля набора схемы КД – оптимизация текста запроса (только последнего запроса в пакете) не случится.
А еще компоновщик игнорирует вложенные запросы! Совсем-совсем! Не совсем, но почти!
(С параметризацией виртуальных таблиц во вложенных запросах компоновщик все-таки справляется. Но это немножко из другой оперы!)
Уперлись, видимо, разработчики компоновщика в не уникальность круглых скобок (обрамляющих вложенный запрос) в тексте запроса. Были бы они квадратные – оптимизация, вероятно, давно бы состоялась (навскидку, поместить текст вложенного запроса во временную таблицу выше, применить алгоритм оптимизации и вернуть обратно – технически, вполне, возможно. Даже с учетом «многоуровнести» вложенности запросов). НО! Нерешаемых задач, ведь, нет! Может, пора уже эту задачу решить?
Или алгоритм компоновщика появился в платформе раньше, чем вложенные запросы. И живет по принципу: «работает – не трогай»! (Ответ на вопрос в комментариях дал tormozit. Вложенные запросы появились раньше. НО! Автору (очень сильно) не нравится принцип! Пусть, вопрос останется!)
УДАЛЕНИЕ НЕНУЖНЫХ ТАБЛИЦ И СОЕДИНЕНИЙ
Компоновщик может сам удалить из запроса ненужные временные таблицы, если с ними отсутствуют соединения или объединения.
Во всех остальных случаях компоновщику нужно помочь – оставить инструкции, какие соединения между таблицами являются необязательными.
По умолчанию, если мы сделали обязательное соединение в запросе и не вывели поля из правого набора в отчет – мы получим следующую картину:
Но, если мы сделаем соединение «необязательным» (за это отвечают фигурные скобочки) - временная таблица из текста запроса будет полностью исключена:
Работает алгоритм исключения ненужных таблиц из текста запроса примерно по следующей логике:
Нам же это дает преимущество: в один запрос можно заложить сбор данных для разных вариантов отчета (кратких и расширенных). Запрос всегда будет «хороший»! Не плодите десятки одинаковых форм – сделайте одну. Одну сопровождать проще!
«МИНИМИЗАЦИЯ СТРОК». ПОЛЬЗОВАТЕЛЬСКИЕ ОТБОРЫ
Если пользователь установит в отчете отбор по какому-либо полю, компоновщик постарается в исходный текст запроса подставить условие «ГДЕ» на это поле (или параметризовать виртуальную таблицу). Пример корректной автоматической расстановки условий:
Но, стоит нам немного пошалить (переименуем поле) - и алгоритм начинает сбоить:
Что можно путем эксперимента выяснить про алгоритм расстановки условий:
- Расстановка условий выполняется до удаления полей (в т.ч. для необязательных таблиц).
- Алгоритм анализирует только временные таблицы и виды соединений (левое/внутреннее) между ними.
- Во временных таблицах алгоритм анализирует только наличие поля, имя которого (после как) соответствует полю, на которое установлен отбор.
- Алгоритм, м.б. как-то анализирует метаданные, т.к. параметризация виртуальных таблиц выполняется только, если имя измерения совпало с именем поля отбора. И принудительно пытается параметризовать виртуальную таблицу, даже если измерение не выбрано в тексте запроса.
- После левого соединения, если поле выбрано из правого набора, устанавливается повторный отбор.
- АЛГОРИТМ НЕ АНАЛИЗИРУЕТ условия соединений между временными таблицами и не анализирует «трансформации» поля по тексту запроса.
- Вложенные запросы игнорируются.
Скорее всего алгоритм работает примерно следующим образом («исходники», естественно, я не видела -могу только предполагать. Но противоречий с описанной логикой пока не выявила, и, на 90% уверена, что работает он примерно так).
Из временных таблиц составляется «пусть будет дерево» («новобранцы» - выпускники ВУЗов, что это за структура данных и как называется алгоритм обхода?), где корнем является последний запрос в пакете, а листьями - временные таблицы, в которых нет выборки данных из других временных таблиц. В узлах этого «дерева» сливаются в левых и внутренних соединениях временные таблицы (и/или/не выбираются доп. данные из БД), стремясь «объединиться в единое целое» в последнем запросе пакета. Выстраиваются все цепочки «слияний» временных таблиц от листьев до корня. Циклов здесь быть не может (ВТ не может являться источником данных для самой себя). Вероятно, рассчитывается для каждого узла максимальная длина пути до корня, и в порядке убывания этой величины выполняется обход. (Объединения в запросах, вероятно, разбиваются на отдельные узлы и сливаются в один вспомогательный).
- Если в узле есть поле (с нужным наименованием), и нет отбора в поддеревьях –устанавливается отбор.
- Если в узле внутреннее соединение между ВТ– и есть отбор в поддеревьях (соответствующих этим ВТ) – отбор не нужен.
- Если в узле левое соединение тогда:
- Если в поддереве, соответствующем, правому набору был отбор, а в соответствующем левому отсутствует – устанавливается дополнительный отбор (на поле правого набора).
- Если в поддереве, соответствующему левому набору – был, то отбор не устанавливается.
Главное здесь:
- не выполняется анализ, выбрано ли поле из БД;
- не анализируются условия соединений;
- не анализируется – пропадало ли поле/ появлялось/ переименовывалось/ переопределялось.
Ключевое для алгоритма – был ли в поддеревьях отбор.
Следовательно, для того, чтобы алгоритм работал корректно (если ничего дополнительно не предпринимать):
- Если поле присутствует в последнем тексте запроса, то от любой временной таблицы, в которой это поле появилось, оно должно без переименований и модификаций (исключение – проверка на ЕстьNull) «дойти до финиша». Или пропасть (из правого набора) в условии соединения. (Пропадать и вновь появляться от листьев к корню по цепочке ВТ оно не должно). Вводить по тексту запроса разные «сущности» с одинаковым наименованием (с целью позднее переименовать) также запрещено.
Переименования полей по тексту запроса приводят к некорректной работе алгоритма.
Переопределение полей тоже:
- При левом соединении поле не может быть выбрано из правого набора, отсутствовать в условии соединения, и присутствовать в левом наборе. (Вообще - это логическая ошибка построения запроса).
- Переименовывать при выборке из виртуальных таблиц измерения – запрещено.
- Если по каким-то причинам отбор на уровне временной таблицы не должен сработать – необходимо принудительно переименовать поле. (уникальное наименование, не встречающееся по тексту запроса). И в нужном месте переименовать «обратно».
- Для виртуальных таблиц срабатывает принудительная параметризация на не выбранное измерение, если его имя совпадает с именем поля, на которое установлен отбор. Т.е. названия выбираемых по тексту запроса ниже полей не должны совпадать с именами не выбранных измерений виртуальной таблицы. (И если у нас две виртуальные таблицы с одинаковыми названиями измерений, в одной из которых нужен отбор, а во второй нет - заходим в тупик).
- Выбирать данные из БД во вложенных запросах запрещено. Причем, смотрите, как интересно - с установкой отбора после левого соединения ВТ во вложенных запросах , алгоритм все-таки справляется:
ПРОБЛЕМА УСТАНОВКИ ОТБОРОВ НА РЕСУРСЫ
Давайте сразу уточним – под «ресурсами» понимаем только количественные и суммовые поля. Если вы, вдруг, группируете даты в массив или делаете конкатенацию строк – для нас это не ресурсы, а аналитики (которые пользователю зачем-то в одной ячейке нужны).
Проблема с ресурсами в том, что отбор на них почти всегда работает некорректно, если взглянуть на это глазами пользователя. Пользователь меняет состав полей в отчете, устанавливает отбор и ожидает, что он будет применен к итоговой сумме по группировке. Лезть в настройки для разработчика и устанавливать там отборы на уровне группировки – это слишком сложно и непонятно.
Для установки отборов по ресурсам, срабатывает точно такая же логика, как и для всех остальных полей – отбор накладывается в первом (по «дереву» ВТ) месте появления поля в запросе (и после левых соединений вт на поля правых наборов). С учетом удаления лишних полей в зависимости от пользовательской настройки – к чему этот отбор будет применен, предугадать невозможно.
Даже, если «отключить» принудительно установку отбора до последнего запроса в пакете, то все равно отбор будет некорректным – он не к агрегированному значению применяется, а просто к выбранному полю.
Задачу можно решить принудительным суммированием (с отключением промежуточного отбора) в последнем запросе пакета:
Тогда отбор все-таки будет применен к агрегированному значению (но если будут обязательные поля, не выведенные в отчет - все-равно будет работать некорректно). А еще, не поверите – проблема решается просто запретом установки отборов на ресурсы. Или запретом редактирования структуры отчета. Так тоже МОЖНО.
ПРОЧИЕ МОДИФИКАЦИИ ТЕКСТА ЗАПРОСА
Чаще всего галку «Автозаполнение» разработчика заставляет снимать некорректная параметризация виртуальных таблиц по периоду. Независимо от того, прописаны ли параметры-периоды в запросе, принудительно добавляются параметры с определенными наименованиями в параметры схемы компоновки. И, если вдруг эти параметры будут установлены – компоновщик пропишет их в текст исполняемого запроса.
Проблема возникнет, например, если:
- Срезы последних/обороты нужны на/за разные периоды в одном запросе.
- Если хотим и обороты, и срез последних в одном запросе.
- Если нужен запрос к таблице итогов регистра сведений (для этого параметризации по периоду не нужна).
А если автоматически добавленному параметру «Период» (для среза последних) тип переопределить на «стандартный период» - отчет вообще формироваться не будет.
«РАЗМЫШЛИЗМЫ»
Вы можете все, что я выше описала, при создании запроса для СКД в голове удержать (и, естественно, соблюсти)?... Заниматься переименованиями полей, только для того, чтобы отбор не сработал – звучит бредово. Плюс еще и ограничение на выборку из БД во вложенных запросах.
Гадать – угадает ли компоновщик с расстановкой отборов по тексту запроса - не хочется.
Документации нормальной по данному вопросу от фирмы 1С у нас нет. Вообще никакой нет(((
(Вот, кстати, больная тема, а по какому вопросу она у нас вообще есть? Фирма 1С мается - не знает, как квалифицированные кадры получить. Внедряют систему наставничества, ИИ активно рекламируют, чтобы он нам стажеров (?м)учил (ну вот как можно «неокрепшим молодым умам» давать игрушку, которая на одинаковом коде различные рекомендации выдает?!!).
Я знаю ответ на этот вопрос. ДОКУМЕНТАЦИЮ НОРМАЛЬНУЮ НУЖНО НАПИСАТЬ! ЕМКУЮ И ЧИТАЕМУЮ! Без «перлов» на подобии «управляемой формы, единой в двух ипостасях &НаКлиенте и &НаСервере». И без "зубодробительного" компоновщика макета компоновки данных. Пока документации не будет – квалифицированных специалистов ждать бесполезно!)
Какой из этого всего вывод? Контролируем процесс самостоятельно! Тем более, что все возможности у нас для этого есть.
ИНСТРУКЦИИ КОМПОНОВЩИКУ. СНИМАЕМ ГАЛКУ
Нам доступны три вида инструкций компоновщику. Две из них позволяют управлять модификациями текста запроса. (третья – только через ошибку, когда ненужные поля не удаляются из текста последнего запроса). Доступны они на закладке «Компоновка данных».
(Абсолютно дурацкое, кстати, название! Предлагаю переименовать в «Оптимизация». Слово модное, привлекательное –сразу и интерес у разработчиков появится (и букв в слове меньше)! Чувствуете, как красиво с правильно подобранным названием смыслы смещаются?)
- Необязательные соединения между таблицами. Уже разобрали выше. Не хотите ставить скобки в тексте запроса – снимайте галки. Единственное, что стоит дополнить – все, что в скобках (а там может быть несколько таблиц) удаляется по принципу «все или ничего».
- Формирование списка полей набора схемы компоновки данных доступных для вывода.
- «Нежесткая» параметризация (одновременно и инструкция для формирования полей набора схемы, доступных для отбора).
Инструкции по формированию полей набора схемы (доступных для вывода)
Немного остановимся на втором виде инструкций. Опытным путем выявлено, что:
- Поля формируются (при снятой галке) только по инструкциям последнего запроса пакета.
- Не влияют на модификацию запроса, если пользователь в отчет выведет какие-то реквизиты доступных полей (через «.») Все что через «.» попадет безусловно в последний запрос пакета. Если у вас поля составного типа или очень большие таблицы – запрещайте выбор реквизитов. (И даже так МОЖНО!)
- Могут запутать компоновщик. (Этот результат получен при установленной галке).
ВЫВОД. Должны находиться только в последнем запросе пакета.
Инструкции для подстановки условий в текст запроса (нежесткой параметризации)
Тут тоже все просто. Можно указать компоновщику:
- Подставить условие на поле отбора в запрос в секцию «ГДЕ»
- Подставить условие на поле отбора в параметры виртуальной таблицы.
- Подставить условие (или параметр-период виртуальной таблицы), если пользователь заполнил необязательный параметр. С полями так, кстати, не получится (подставить отбор на поле, если пользователь вывел это поле в отчет).
(Вот, кстати, а что помешало разработчикам платформы при снятии галки автоматически инструкции в текст запроса добавлять? Алгоритм же есть! Заглушку от плохих запросов к БД в виде галки сделали, а вот от не очень умного разработчика 1с, который эту галку может снять –нет. Нелогично. Снова ограничения синтаксиса?)
ИНСТРУКЦИИ VS АЛГОРИТМ
А что будет, если одновременно оставить галку и указать инструкции?
Если условие установить ниже по тексту запроса, чем место, которое рассчитает алгоритм компоновщика - отбор будет подставлен и по инструкции, и по алгоритму.
А вот если выше – то только по инструкции. Из чего можно сделать вывод, что сначала расставляются («по дереву ВТ») отборы по инструкциям, а потом вызывается алгоритм «обхода дерева», который их в т.ч. учитывает.
Причем, похоже, общая схема следующая:
- Расстановка отборов по инструкциям
- Расстановка отборов по алгоритму (если не сняли галку)
- Удаление ненужных полей
- Удаление ненужных таблиц (временные таблицы без соединений (ошибочно оставленные), вероятно, удаляются сразу, в момент построения дерева)
Переубедить, кстати, компоновщик НЕ размещать условие «где» в тексте запроса с помощью инструкций за счет переопределения псевдонима тоже не получится. А вот отключить параметризацию виртуальных таблиц поможет :
«Базовый рецепт» расстановки инструкций для компоновщика
Нам сейчас абсолютно не важно, какой у нас написан запрос (плохой/ хороший/ оптимальный/ неоптимальный…). Наша задача – превратить его в «хороший» для СКД. Сделать это можно следующим образом:
- Делим все выбираемые поля на «аналитики» и «ресурсы». «Ресурсы» – это только суммовые и количественные поля, к которым будем применять агрегатные функции. Все, что не «ресурсы» – это «аналитики».
- Если поле - «аналитика» выбирается из БД (в т.ч. через «.» от ссылки) и отсутствует жесткая параметризация на это поле– обязательно устанавливается «нежесткая» параметризация.
- Если поле «приходит» за счет внутреннего соединения между временными таблицами – параметризация не нужна. (Естественно, на все новое - расчетное или вытаскиваемое из таблиц БД - инструкция.)
- Если поле «приходит» за счет левого соединения между временными таблицами – дополнительная параметризация на поле из правой таблицы (с проверкой на ЕстьNull).
- Ко всем «ресурсам» – нежесткая параметризация на уровне последнего запроса в пакете (с обязательным применением агрегатных функций). Или вообще отборы не разрешать устанавливать.
Когда «базовый рецепт» не работает?
- Когда одна и та же выборка будет анализироваться в разных аналитических разрезах, т.е. отбор «максимально рано» не нужен.
- Когда не уследим за переименованиями/переопределениями.
НО! В чем «прелесть»? Если инструкции расставлены некорректно – это сразу выявится при тестировании/ в процессе эксплуатации. А если не оставлены (например, «плюхнуты» на уровень последнего запроса пакета) – этого никто никогда не найдет и править не будет!.
В чем смысл? Компоновщик же по «базовому рецепту» и работает?
Если вы вдумчиво читали, то у вас сейчас должен резонно возникнуть вопрос. Ответ – ДА! Я предлагаю вам вручную делать примерно ту же работу, которую выполняет компоновщик.
Почему?
Во-первых, когда рецепт «засбоит», а он обязательно «засбоит» – все инструкции по тексту запроса у вас уже будут расставлены. Вам останется их только «опустить» немного ниже по тексту запроса. И вы не получите ситуацию, когда не очень умный разработчик снимет галку и все инструкции на «нежесткие» оборы оставит в последнем запросе пакета!
Во–вторых, компоновщик не может определить, будут ли выбираться данные из БД, он может только на имя поля ориентироваться. А вот вы –да.
В-третьих, когда вы, осознанно, в каждой временной таблице задаете вопрос: «должно ли в этом запросе подставиться условие, если пользователь установит отбор на поле с этим (или оно д.б. не этим?) наименованием – вероятность ошибки на переименованиях/переопределениях/досрочных параметризациях снижается.
В-четвертых, мы даем абсолютно убогие наименования объектам метаданных. Любой, оставленный нами код контекстен. О чем вы думали полгода назад, когда какой-то реквизит наименовывали – тайна, покрытая мраком. Так что переименований не избежать!
В–пятых, вложенные запросы - это отличная функциональность! Иногда за счет избавления от временных таблиц можно очень хорошего ускорения добиться.
И, напоследок - это прекрасное упражнение для мозга. Причем совершенно бесплатно!
Чек-лист.
Перед началом работы.
- Вспомнить, что пишете не запрос, а запрос для СКД. Ваш запрос формироваться не будет, а будет формироваться бесконечное множество каких-то других. И все они д.б. «хорошие»!
До открытия конструктора запроса.
- Создать отчет в конфигураторе! Никогда не может создание запроса для СКД начинаться с консоли запросов в пользовательском режиме! ( Вспомнить п.1. Консоль запросов предназначена для написания запросов, а не запросов для СКД!)
- Переопределить метод «ПриКомпоновкеДанных».
- Снять галку «Автозаполнение». (Если в пакетном запросе будет хотя бы одна временная таблица). Пусть вас утешает мысль, что вы умнее алгоритма.
Пишем запрос
- Написать запрос. Расставить инструкции. Создали временную таблицу/вложенный запрос – СРАЗУ заполнили «нежесткие отборы» по "базовому рецепту". Над каждым выбранным полем в каждой временной таблице размышляем, должен ли сработать отбор. (Ну или напишите себе обработку, которая инструкции за вас расставит. Разработчики вы, или кто? UPDATE. Кнопка есть. "Ищите и обрящете" в комментариях. НО! Своей головой, все-таки, контролируемее! А вот надежнее, как ни печально, скорее всего по кнопке...)
- Оставить комментарии для «потомков». Чтобы потом не страдать, вспоминая, что в своем же собственном запросе сотворили.
Проверки
- Проверить, что для всех полей последнего запроса есть инструкции на формирование полей набора схемы (доступных для вывода). Проверить, что во временных таблицах нет инструкций.
- Проверить, что все инструкции для параметризации запроса оставлены:
- Есть выборка из БД и нет нежесткой (или жесткой) параметризации по выбранным полям. Ответить почему.
- Есть выборка из временной таблицы, к которой делается левое соединение. Проверить наличие инструкций на поля из правого набора с проверкой на ЕстьNULL.
- Проверить расшифровки. Все поля исходной группировки должны попасть в отбор.
- Проверить, что не было переименований полей (до «как» и после). Если были – перепроверить инструкции компоновщику.
- Проверить поля наборы схемы на «странные» наименования. Уделить внимание полям, доступным только для отбора. Если есть – перепроверить инструкции.
- Проверить текст запроса на наличие конструкции «Сгруппировать» и «Различные». Можно для проверки удалить поля группировки из выводимых полей. Если результат некорректный – сделать поля обязательными.
- Проверить соединения между таблицами. Ответить на вопрос, точно ли должны быть обязательными?
- Проверить запрос на наличие вложенных. Вспомнить, что алгоритм оптимизации не справляется с удалением невостребованных полей из вложенных запросов. (Не должно быть в них много "полезного" про запас.)
- Проверить периодичность виртуальных таблиц оборотов РН. Не должно быть меньше месяца. В идеале – д.б. «АВТО» или «Период».
Не может платформа ничего «оптимизировать» (опять проблема отсутствия нормальной документации), если периодичность меньше месяца –это детерминировано логикой хранения данных в БД в двух таблицах (в одной общие суммы за месяц, в другой – все данные). Платформа только «сгруппировать» (это разве оптимизация?) в текст запроса по таблице движений сможет добавить – с этим вы способны справиться самостоятельно. Не занимайтесь самообманом – пишите запрос к основной таблице, чтобы не получалась такая «красота» в виде соединения таблицы оборотов с основной таблицей ради реквизитов.
Отладка
- Отлаживать ТОЛЬКО исполняемый запрос. Все правки вносить только в конфигураторе.
На этом наше исследование подошло к концу. Пишите запросы для СКД правильно!
P.S. Так он все-таки иногда выполняется? Или все-таки нет?
После того, как найдете подтверждение, что он все-таки "ИНОГДА" выполняется, ответьте на вопрос: "А пользователю это надо"?
P.S.2 Мне кажется, мой труд заслуживает спасибо, даже, если где-то были допущены неточности. (Если найдете - пишите. Поправим.) Как минимум потому, что редактор текста на данном сайте очень похож на инструмент для пыток. Гадости (под "гадостями" автор понимает в т.ч. не аргументированную критику), «испражнения» и не объединенные общим смыслом наборы букв оставляйте, пожалуйста, при себе. "Оно" мне мне не надо (могу и вернуть!). Претензии по качеству скриншотов (с нечетким изображением) – напрямую разработчикам сайта (ибо у широких скриншотов, при автоматическом уменьшении размера, существенно страдает четкость!).
P.S.3 Ну и, конечно, ЛЮБИТЕ СКД ТАК, КАК ЛЮБЛЮ ЕЕ Я! И ДОЛОЙ СТЕРЕОТИПЫ – СВОБОДУ МЫСЛИ!
UPDATE. Почитав комментарии под статьей, автор, кроме стереотипности мышления, также предлагает объявить войну комплексам, хамству и безграмотности(((
Вступайте в нашу телеграмм-группу Инфостарт
архитекторы развлекаются любите СКД долой стереотипы пофилосовствуем? 1С дай документацию
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструментарий разработчика Роли и права Запросы СКД Разработчик Руководитель проекта 1С:Предприятие 8 Платные (руб)
Инструменты для разработчиков 1С 8.3 и 8.5: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.
16500 руб.
02.09.2020 286433 1611 423
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Как решить проблему с отборами по полям СКД, когда с одинаковым отбором Отчет показывает одно, а Консоль запросов другое.
16.06.2026 6438 sapervodichka 45
Инструментарий разработчика СКД Разработчик 1С 8.3 Бесплатно (free)
В этой статье представлен ПовелительОтчетов — общий модуль-обёртка над объектной моделью СКД, который сокращает код в 3-4 раза и делает его читаемым.
29.01.2026 9531 458 shapa_pro 31
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Описан способ заполнения списка доступных значений для полей наборов данных и параметров в схеме компоновки данных для любых конфигураций (с использованием БСП или без).
01.07.2025 15899 krasnoshchekovpavel 7
СКД Разработчик Стажер 1С:Предприятие 8 Россия Бесплатно (free)
Несколько способов управления формами выбора параметров и отборов СКД.
10.04.2025 15299 Neti 0
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Хорошая отчетная форма - сродни искусству. Есть какое-то невероятное эстетическое удовольствие в том, чтобы разобраться в логике учета и анализируемых показателях, спроектировать архитектуру хранения данных так, чтобы оптимально собрать эти показатели вместе с аналитическими разрезами в запросе, а затем настроить отображение так, чтобы, глядя на результат, сразу было понятно, что это за отчет и какие задачи он призван решать. Система компоновки данных - это моя первая, главная и, наверное, единственная "рабочая" любовь. Ее я использую везде, где только можно и где нельзя тоже. Хочу поделиться с вами некоторыми практическими приемами в работе с отчетами на СКД, которые, надеюсь, будут полезны.
27.02.2025 19907 ovetgana 50
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
СКД – инструмент, на базе которого в современных конфигурациях реализованы практически все отчеты. СКД используется в динамических списках, печатных формах и универсальных механизмах. Если построить простейший отчет может каждый разработчик, то с нюансами знакомы далеко не все. Расскажем о неочевидных на первый взгляд приемах, способных значительно повысить качество отчетов.
24.12.2024 17812 Akcium 17
СКД Механизмы типовых конфигураций Запросы Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)
Работая с типовыми отчетами в конфигурациях «Зарплата и управление персоналом, редакция 3», «Зарплата и кадры государственного учреждения, редакция 3» и подобных, в схемах компоновки данных можно встретить конструкции запросов, которые обращаются к некоторым виртуальным таблицам.
20.08.2024 16594 AlexeyPROSTO_1C 3
Слово инженер заимствовано из французского ingénieur, которое в свою очередь восходит к латинскому ingenium.
Буквы "е", "и" взаимопереходящие, также как "г", "ж", поэтому неудивительно, что мы, простые носители языка, не озабоченные его литературностью, по-разному используем эти переходы.
...а примеры вида "до" и "после" выглядят сложно-сравнимыми либо, вообще, несопоставимыми
и
?
Есть пара вопросов.
"Если вы сейчас решили, что я призываю вас переопределять поля представления - вы не правы. НЕ ВЗДУМАЙТЕ это делать!"
Если я ничего не путаю, то как раз таки если тянем представление, то СУБД вообще ничего с ним сделать не может, в т.ч. и упорядочить, отобрать или сгруппировать.
За получение представления или представления ссылки (именно поэтому мы в запросе вообще почти ничего с этим представлением делать не можем) отвечает сама платформа, и тут
можем попасть, например, если кто-то криво переопределил обработчик получения представления.
В связи с этим не ясно, чем это хуже получения, например, наименования в качестве представления?
Разумеется, если нет требования всегда показывать ссылку как этого "хочет" обработчик представления объекта.
============================================================
"Например, если для поля составного типа нужно получить представление, скорее всего платформа сформирует отдельные запросы для массива ссылок к разным таблицам, а не сделает левое соединение с безумным количеством таблиц в запросе."
И что? Заменит 10 левых соединений по индексу (т.е. ссылке), на, например, получение, непонятно откуда, массива ссылок, создание объединение из 10 разных таблиц с последующим соединением по ссылке же с основной таблицей?
Как вообще это выглядит на практике?
Может кто-то уже с этим разбирался?
С какого-то момента картинки стали обрезаться до 1024. Писал полгода назад в техподдержку, сначала обнадежили, мол проблема передана разработчикам, ожидайте. Потом перестали отвечать, тупо игнорят. Ну блин, напишите что мол так и так, кризис экономим место, все понял-бы и простил.
Даже в канал им писал, они там танцульки устраивают, все у них замечательно.
Странное правило. Схрена ли гости понаехали? Вас жестоко обманули. В пользовательском режиме запрос удобно отлаживать. Потом можно допилить для СКД. Зачем страдать, если результат одинаков?
Боюсь, что совет для начинающих изучать 1С в статью для продвинутых писателей запросов попал случайно.
Потому что потом - никогда не наступает. Если вы способны себя дисциплинировать и после того как отладите запрос в консоли, пойти и инструкции расставить - вы в полном праве так поступать. Большинство с этой задачей не справляется. И, кстати, я прекрасно осведомлена про наличие ИР и консоли отчетов. Для меня они бесполезны, я к ним прибегаю крайне редко. Про проблему промежуточной отладки запросов я уже очень давно забыла. Верю, что она есть, но абсолютно честно много лет не понимаю зачем. Запрос нужно писать сразу от и до. Что там непонятного? А правки в двух местах: и в конфигураторе и в пользовательском режиме - приводят к тому, что обязательно что-то теряется. Неэффективная трата времени.
2. Ваш подход "писать сразу правильно" хорош, если разработчик досконально знает и конфигурацию и данные. Плюс, если заказчик или аналитик точно поставил исполнимую задачу. Чаще встречаются случаи, когда нужно проверить как оптимальнее брать данные, заполнены ли они, возможно ли получить требуемое, а если нет, то какая дополнительная обработка требуется. А ещё некоторые аналитики вполне пользуются консолью запросов и консолью СКД.
Бурную реакцию читателей вызывает даже не материал, а форма его подачи.
Безапелляционные заявления с повышением тона:
Красный шрифт с восклицательными знаками:
Инструкция, очень похожая на пошаговый приказ:
Вы пишете статью для коллег, которые, вполне вероятно, не уступают Вам в квалификации и самооценке, поэтому не стоит удивляться отторжению, которое вызывает её тон.
Если же вы нарочно эпатируете коллег, то моё почтение за смелость. Бойцов я уважаю.
Если Вы внимательно читали - то это презентационные материалы, на которых, естественно, ключевое выделялось цветом и шрифтом.
(26)
Бурную реакцию читателей вызывает даже не материал, а форма его подачи.
Безапелляционные заявления с повышением тона:
запрос, помещенный в схему компоновки данных, НИКОГДА НЕ ВЫПОЛНЯЕТСЯ.
Я открыта к диалогу. Докажите обратное.
(26)
переименований не избежать!
И? Что не так? Я сама на наименованиях косячу. А уж что, разработчики вокруг меня творят... Так что переименований по тексту запроса не избежать, что приведет к некорректной работе алгоритма при оставленной галке. Что вас обидело?
(26)
Создать отчет в конфигураторе!
Вообще-то, это чек-лист. Он и должен быть в повелительном наклонении написан. Плюс наполовину - это шутка юмора. Акцент был на том, что сразу оставить инструкции проще, чем когда-нибудь потом.
Короче, я не понимаю, что вас так негативно зацепило.
тоже покоробила безальтернативность суждений
если запрос содержит простые типы и перечисления и все поля выводятся в детальные записи, то с запросом ничего не происходит (см. доказательство в прикрепленном файле)
А теперь, если выйти из лабораторных условий в реальный мир, то возникает вопрос - а нужен ли пользователю такой отчет? Сколько реально создано отчетов (для использования, а не эксперимента), при формировании которых исполняемый текст запроса совпадет с исходным? Мне кажется, процент от общего количества стремится к нулю.
Про безальтернативность где-то ниже отвечала. Это додумки.
Естественно, при доп. настройки будут вносится изменения в текст запроса - и эта возможность была еще в 8.0 при использовании построителя запроса или построителя отчета (собственно, в статье исследована только возможности построителя запроса, а не СКД)
Но утверждение звучало как "запрос, помещенный в схему компоновки данных, НИКОГДА НЕ ВЫПОЛНЯЕТСЯ" и его неверность доказывает пример выше.
Если нужен реальный кейс, то вот пример: ежедневная рассылка отчета в виде плоской таблице Excel для аналитиков, т.е. пишется запрос с параметрами, запрос закидывается в отчет, а по отчету настраивается рассылка.
Про безальтернативность: статья называется "как правильно писать запросы СКД" и я думал рекомендовать её разработчикам команды, но когда стал читать, то увидел много спорных утверждений - одно выше разобрали (хоть оно и носит "лабораторный" характер). Но дальше пошли рекомендации на основе утверждений и часть из них неверны: например, запрет переименования измерений виртуальных таблиц - переименовывать можно, только нужно с помощью инструкций компоновки настроить отбор в параметрах виртуальной таблицы (ниже tormozit описал как это делается). Вот из-за таких рекомендаций я и не буду рекомендовать эту статью.
Во-первых, это девушка.
Во-вторых, на прошлых ее статьях налетели коллеги, ей пришлось закрыть комменты.
У всех своя картина мира и контекст, в котором приходится жить и работать.
Мне очень лестна Ваша забота обо мне. Но я Вас разочарую. Проблема комментариев на данном сайте в том, что они очень глупые - потому комментарии и закрывала. Специально пишешь статью, чтобы читатель мозг включил, подумал, о том как он стереотипно мыслит, поэкспериментировал с кодом, и к каким-то собственным выводам пришел. Вместо этого набегает куча непонятно кого с глупыми, ничем не аргументированными, мнениями. А ничего не понявший читатель, вместо того, чтобы мозг напрячь и собственное мнение сформировать, читает эти глупые комментарии, видит рейтинг, и приходит к выводу, что автор глупость написал. НО, к сожалению, проблема данного сайта - закрываешь комментарии и никто не читает. В чем тогда смысл огромной проделанной работы был?
Какая разница девушка она или парень, с ее слов
С таким отношением к сообществу...
Дальше идет ряд нейтральных благодарных/рекламных/с замечаниями по оформлению (за них спасибо) комментариев. У нас есть два вопроса, на один из которых я м.б. даже попозже отвечу, т.к. у коллеги вполне вероятно нет доступа к MSSQL, и самостоятельно провести исследование он не может. И Ваш - на который Вы вполне самостоятельно могли бы ответить, но почему-то поленились эту работу проделать.
И дальше у нас целая охапка комментариев с какими-то домыслами, в т.ч. лично в мой адрес. Причем ни одного аргумента, где неточности, или ссылок в подтверждение собственных же слов нет. Особо отличившийся товарищ, получив аргументированные возражения, у нас даже обиделся и побежал в соседней ветке гадости писать, противореча своим же собственным, ранее написанным, словам.
Теперь я готова выслушать Ваши аргументы, почему комментарии оставленные под данной статьей в большей своей массе - умные.
Я честно предупредила - гадости не писать. Так что в полном праве развлечься за счет тех, кто предупреждение проигнорировал.
И я очень позитивно отношусь к аргументированной критике - она делает нас лучше. К сожалению, под данной статьей был оставлен только один критический комментарий, из которого сделан вывод, что с некоторыми скринами я на самом деле накосячила. Могло быть лучше. Все остальное - это не про замечания. А попытки самоутвердиться за чужой счет, причем с достаточно грубыми формулировками и разводом на эмоции. Ваш комментарий такой же.
Вместо того чтобы сразу опубликовывать материал на инфостарте - сначала публикую её на гитхабе и прошу в публичных тг-чатах найти ошибки. Тут срабатывает человеческая психология, люди любят указывать в чём автор не прав и критиковать. И вот уже после рецензий от контрольной группы редактирую все проблемные места и выкладываю в паблик. Чуть-чуть помогает)
ЗЫ: 116 попугаев в серверной - это результат?
С другой - кажется что вместо изучения документации (да, она сложная и запутанная) было больше экспериментов, с не всегда корректными выводами.
(16)
Уважаемые, я считаю, что за собственные слова нужно отвечать. Я за каждое слово в любой своей статье ответить готова. Будьте добры - ссылку на документацию, в которой описано поведение алгоритма модификации текста запроса, ограничения его использования и рекомендации при снятии галки. Если все, чем вы меня порадовать сможете - это , то это даже не смешно будет.
Список неточных выводов - предъявляем. Я проанализирую и, если соглашусь с ними, внесу правки.
Также прошу просветить меня, как же именно некорректно я использовала данный инструмент. Немного вводных -я очень много лет, осознавая, что алгоритм расстановки отборов по тексту запроса работает не всегда корректно, снимаю галку и расставляю инструкции по собственному рецепту. В моем подразделении галка запрещена на уровне регламента. А, как оказывается "обратный инжиниринг", появился в рамках аргументации, почему галку нужно снимать. Причем я была приятно удивлена спустя много лет поняв, что алгоритм пытается реализовать ровно ту логику, по которой я самостоятельно инструкции расставляю, и достаточно успешно во многих случаях с задачей справляется. Теперь жду от вас список моих ошибок.
полей и значений параметров не всегда оптимально и иногда может привести
к ошибкам.
и
данных: система исключает из результирующего запроса поля, не участвующие в настройках отчета. Это также может приводить к ошибкам.
Если из 11 скриншотов (до и после) в этой главе с запросами (даже без временных таблиц) к виртуальной таблице регистра накопления, для Вас очевидна вся логика работы алгоритма по модификации текста запроса и его ограничения - видимо, Вы куда умнее меня.
Автор проделала огромную работу по обратному инжинирингу и тестированию вместо изучения документации.
СКД очень мощный и классный инструмент, и пофиг что он запросы раздувает и меняет их, если ты понимаешь как он работает он сделает ровно то что ты от него хочешь. Я на СКД пишу уже очень давно, многих моментов не знаю, постоянно узнаю что-то новое, НО никогда у меня не было каких либо сверх сложных проблем, всегда были решения!
Любой инструмент можно применять неправильно, как автор и делала. Некоторые вещи из всего этого было полезно узнать, но их очень мало из того что я и так знал.
Это скорее страховка и перфекционизм отдельных методологов. Чтобы ни в коем разе лишние поля в выборку не попали. Буквы экономят.
Ещё. При снятой галке легче программно изменять СКД. Но это отдельная тема.
Не полный, а почти полный. В статье есть пример с группировкой, но он плохо подсвечен.
Тут более подробно описано.
Там искажается результат, начиная с непоследнего запроса пакета. Исправить это невозможно через расширение языка запросов для СКД и отключение их автозаполнения.
1. Создать отчет в конфигураторе! Никогда не может создание запроса для СКД начинаться с консоли запросов в пользовательском режиме!
Я начинаю с Хранения - как данные хранятся в базе - возможно надо добавить таблиц и логики для получения нужных сведений быстрее... Плюс, есть у меня пример, когда я сложный отчет (запрос) СКД переделал под обработку и вывод в табличную часть обработки.
Есть отчет АВС-анализ - я его из СКД полностью переделал под обработку с табличной частью, с возможностью задавать параметры диапазонов, сами диапазоны, разрезы проведения анализа - в обработке в цикле внутри цикла был произведен сложный алгоритм расчета показателей - получилось даже интереснее, чем отчет на СКД. На СКД он выглядел громоздко, выполнялся долго и тяжело сопровождался - не всякий 1сник умеет так сложно писать алгоритмы на языке запросов... Поэтому задача лежала на полке 2 года, пока я "все просто" не сделал. На ИС выложил пример самой простой подобной реализации.
До открытия конструктора запроса.
2. Переопределить метод «ПриКомпоновкеДанных».
В своей практике я переопределял для одной цели - ограничить пользователей видеть "ненужные" данные + автоматом задавать нужные параметры и отборы. Понятно, что это ограниченный круг задач. Но получается, что я не всегда переопределял метод ПриКомпоновке.
После прочтения статьи понял, что нужно переопределять еще в одном случае - если не получается выйти на нужную структуру и нужные результаты, тогда для отладки "исполняемого запроса" будет удобно сначала его перехватить. Далее, получаем исполняемый запрос и копируем его в консоль запросов пользователя для отладки. За эту идею спасибо.
3. Снять галку «Автозаполнение». (Если в пакетном запросе будет хотя бы одна временная таблица). Пусть вас утешает мысль, что вы умнее алгоритма.
Кто-то до меня снял галочку для отчета простой структуры Доходы-Раходы: НачПериода, Приход, Расход, КонПериод - всего 8 полей. Далее понадобилось добавить поля " Без НДС" и "С НДС" - то есть добавил еще 16 полей. Вместо одного часа работы, потратил 16 часов. Там каждое поле нужно было вручную прописать - какую "роль" оно играет - нач. остаток или конечный, переименовать его красиво... при доработке отчета пришлось воспользоваться вот этой статьей
Я проверил, если бы не снимали эту галку "Автозаполнение", то отчет был такой же, но сопровождать его становится намного легче и быстрее - добавить 16 полей "с ндс" и "без ндс" - получилось бы за пару часов.
Плюс у меня, есть стойкое отношение, выработанное на работах для одной компании - им не нужны "различные" настройки отчетов, им нужны красивые сложноструктурированные отчеты - которые ложатся на стол в бумажном виде аналитикам, руководству и попадают в таком виде на отчетные заседания высшего руководства. Это не экселевские таблицы с тысячей строк, а итоги в разрезе подразделений, периодов. Так вот, подобные отчеты я не делаю через СКД, делаю через макет табличного документа - и подстановку полученных сведений в поля. В общем-то работает без СКД.
ПС. В целом, кроме вашего исследования на ИС описано много нюансов работы СКД - много полезного и много прям совсем "нюансов" черного ящика СКД. Полагаю, что этим исследование СКД не заканчивается.
ПС2. Вы много упоминали новичков, стажеров, которые слов "компоновка" не знают, и сразу выдали им свою "базу"... Возможно, все же им стоит начать с консоли запросов пользователя - чтобы прочувствовать другую "базу"....
ПС3. Вы также с некоторым сомнением описывали логику работы СКД (так, как вы понимаете СКД). Остается непонятным, делали ли вы попытки написать в техподдержку 1с-разработчикам, и какой ответ от них получали...
ПС4. За 15 лет уже не хочется писать только умные комментарии, в последнее время хочется ощутить сопричастность к сообществу, и иногда поддержать автора заочно и авансом. К слову сказать, первый пост был мой. И он говорит лишь о хорошем моем расположении к автору статьи, а не о моих способностях и расписках в несостоятельности.
Всем хоккей! :)
Посмотрите, пожалуйста, последние два слова в данной статье, и подумайте, может ли статья, в которой автор "безапеляционно" требует следовать рекомендациям в тексте, заканчиваться ими.
Естественно, разработчик 1С должен и консолью запросов владеть и знать про возможности СКД. Любое техническое решение, решающее баланс Качество/Скорость/Цена и не приводящее к проблемам является правомерным. Если пользователям нужна форма, чтобы распечатать, подписать и вложить в папочку, то функциональность СКД может для них быть ненужным усложнением. А какому-то крайне важна возможность установки отборов/донастройки для анализа. И тогда разработчик должен понимать, как работает СКД. Я перед собой задачу написать документацию за 1с по всем вопросам не ставила. Эта статья посвящена только описанию логики модификации текста запроса.
Проблема СКД в том, что на самом деле очень плохая терминология (документацию не читают), и в том, что методологи 1С не смогли сформулировать простую мысль: Запрос в СКД должен решать задачу минимизации выбираемых (из БД) данных. Про алгоритм модификации текста запроса есть буквально пару заметок на ИТС (которые очень сложно найти через поисковые запросы) из которых хоть что-то про его работу можно понять. Документация на ИТС вообще в последнее время на помойку похожа. Я очень много со стажерами работаю, и вижу как сильно не хватает хорошей документации, которую можно легко найти, быстро прочитать, и в которой не будет "двойных смыслов". Мне ее самой не хватает.
Приводит это к тому, что разработчик, столкнувшись с непонятным поведение запроса, не может найти ответ, почему так происходит, и решает СКД не пользоваться (после чего появляются комментарии "А я не люблю СКД" ). Или снимает галку и все инструкции оставляет в последнем запросе пакета - такой красоты очень много. А если система нагруженная, отчетов много, то база начинает "загибаться".
И это обидно, т.к. это очень крутой алгоритм. Да у него есть ограничения (причем, как мне кажется, негласный запрет на вложенные запросы (вместо соединений с вложенными запросам) появился как раз исходя из ограничений этого алгоритма). И хотелось бы, чтобы 1С сама эти ограничения описала, но почему-то за много лет руки у них так до этого не дошли.
Лично я в этом алгоритме вижу огромный потенциал - именно про это у меня три другие статьи написаны. Можно написать один запрос и за счет инструкций получать десятки разных других, причем к БД всегда будет выполняться оптимальный запрос. Это актуально, например, для систем с большим количеством изменений. Если определенная выборка данных нужна в десятке различных мест, можно не в десятках мест дырки после очередного изменения закрывать, а только в одном. Потому всегда снимаю галку и все модификации контролирую самостоятельно. Как это делать - в этой статье поделилась.
Никакой другой смысл в статью не закладывался, кроме призыва думать своей головой, а не чужой.
Хорошего Вам дня и не пишите больше про себя гадости ради чувства причастности к сообществу.
- это не то, что вы думаете:
это чтобы поддержать автора, и вывести его статью на главную страницу... я продолжу поощрять авторов таким способом.... прочитать такой объем я смогу на выходных, а не в рабочее время в будни...
платформа и конфигурации всегда были сложными в плане того, что имели в себе косяки и непонятности, документации всегда не хватало, со временем к этому привыкаешь, и лишь благодаря сообществу все вопросы начали решаться очень быстро...
Слово - страшная сила. Им пользоваться аккуратно нужно.
Я Вам прощаю (18) - унизительный (для меня как профессионала) комментарий в мой адрес. Мир, дружба, жвачка!
на
Пример. Есть элемент справочника с названием "ИП Самсонов" или "Запрос 1", помещенный в БД. Я открыл его форму и изменил в нем комментарий и записал в БД. Дальше я упоминаю его в какой то инструкции опять же в виде - "ИП самсонов" или "Запрос 1". Как будет читатель понимать, что речь идет о конкретном состоянии/версии этого элемента или о всех его состояниях/версиях обобщенно?
заменить "приведет к ошибке" на "приведет к искажению результата", т.к. при выполнении запроса могут возникать и те ошибки, которые по-другому не назовешь (например деление на ноль). Причем на картинке текст почти так и сформулирован, т.е. без двусмысленности.
на более четкое
и
на соответственно
некорректны, т.к. похоже написаны без учета возможности назначать полям отбора виртуальных таблиц псевдонимы в фигурных скобках.
1. Поэтому нет смысла запрещать "переименование", т.е. назначение нестандартных псевдонимов, таким полям.
Пример
Наложим отбор по полю "МояВалюта" в запросе
ВЫБРАТЬ
Т.Валюта КАК МояВалюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, {Валюта.* КАК МояВалюта}) КАК Тполучим
ВЫБРАТЬ
Т.Валюта КАК МояВалюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, (Валюта) = &П) КАК Т2. И нет тупика в случае двух виртуальных таблиц с одинаковыми именами полей отбора виртуальных таблиц. Достаточно назначить тому полю, на которое отбор накладывать не нужно, уникальный псевдоним и скрыть его доступность для пользователя.
Пример
Наложим отбор по полю "Валюта" в запросе
ВЫБРАТЬ
Т.Валюта КАК МояВалюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, {Валюта.* КАК МояВалюта}) КАК Т
;
ВЫБРАТЬ
Т.Валюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних() КАК Т Показатьполучим
ВЫБРАТЬ
Т.Валюта КАК МояВалюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, ) КАК Т
;
ВЫБРАТЬ
Т.Валюта КАК Валюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, (Валюта) = &П) КАК Т Показать
Я как и многие, этого не понял. Возможно не внимательно читал. Подскажи, где это указано.
Даже если выше это явно указано, то запрещать все равно опасно, т.к. подобные большие тексты люди часто не читают целиком, а лишь фрагментами. Поэтому опасно важный контекст столь категоричных утверждений уносить далеко.
Предлагаю там же сделать небольшие комментарии, что далее будут рассмотрены способы обойти эти проблемы.
(78)
Да, далее в статье увидел это и удивился, что сначала в статье запрещается переименование, а потом вскользь описывается как нарушить этот запрет. Опять это из-за того, что я не понимал что в первой части "рассматривается только автоматическая логика работы алгоритма".
Предлагаю более явно в первой части статьи обозначить, что она рассматривает только режим без инструкций компоновки.
Некорректное утверждение. Отборы виртуальных таблиц компоновка видит на любом уровне вложенности.
Пример.
Наложим отбор по полю "Валюта" на запрос
ВЫБРАТЬ
Т.Валюта КАК Валюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних КАК Т,
(ВЫБРАТЬ
1
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалют_СрезПоследнихТ) КАК КурсыВалют_СрезПоследнихТполучим
ВЫБРАТЬ
Т.Валюта КАК Валюта
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, (Валюта) = &П) КАК Т,
(ВЫБРАТЬ
1 КАК Поле1
ИЗ
РегистрСведений.КурсыВалют.СрезПоследних(, (Валюта) = &П) КАК КурсыВалют_СрезПоследнихТ) КАК КурсыВалют_СрезПоследнихТПоэтому предлагаю такую формулировку
Давно я просил подобную возможность у них
Устал ждать и написал свой конструктор запроса с такой функцией
Я не нашла описаний ограничения использования кнопки. Есть документация? Если нет, то по-уму этой кнопкой можете пользоваться только Вы сами, и, м.б. Ваши ученики. Или нужно отдельное исследование проводить уже Вашего алгоритма. Сомневаюсь, что многие осознанно перепроверяют полученный результат, не смотря на предупреждение в подсказке. Я пока останусь при мнении, что инструкции лучше расставлять самостоятельно и всегда снимать галку. Не так это много времени отнимает.
Чтобы сделать эту сухую констатацию факта более понятной, предлагаю добавить пояснение.
Флажок "Автозаполнение" динамически добавляет отдельную секцию {ГДЕ} с перечислением всех выбранных в запросе полей. Поэтому пока он включен, назначение своего псевдонима полю в ручной секции {ГДЕ} просто дает полю второе имя, а не переименовывает его.
Пример
Для запроса
ВЫБРАТЬ
Т.Валюта КАК Валюта
ИЗ
РегистрСведений.КурсыВалют КАК Т
{ГДЕ
Т.Валюта.* КАК МояВалюта} // Ручная секция с назначением своего имени
{ГДЕ
Т.Валюта.* КАК Валюта} // Динамическая секция от флажка "Автозаполнение" формируется перечислением всех выбранных полейполучим оба поля (МояВалюта и Валюта) доступными для отбора. При наложении отбора по обоим сразу получим такой запрос
ВЫБРАТЬ
Т.Валюта КАК Валюта,
ИЗ
РегистрСведений.КурсыВалют КАК Т
ГДЕ
Т.Валюта = &П
И Т.Валюта = &П2
Похоже автор не использовал консоль компоновки данных. Я как раз учу всех наоборот делать - по возможности создавать и отлаживать компоновку данных сначала в консоли компоновки данных в связке с консолью запросов. Например такая связка есть в наборе "Инструменты разработчика Tormozit". Там цикл правка-проверка значительно быстрее выполняется и к тому же огромное число всяких высокоуровневых помогалок, которые поясняют и защищают. Потому разработчик отчета экономит массу времени.
Кстати все мои иллюстрации сделаны в той самой консоли компоновки.
Уверен, если бы автор освоил эту консоль, то он сделал бы еще более наглядные иллюстрации и с меньшими усилиями.
1. Потери не сохраненного в пользовательском режиме случаются чаще, чем в конфигураторе.
2. Если правки вносятся в пользовательском режиме, то есть вероятность, что они не попадут в конфигуратор.
3. Промежуточная отладка запроса - бесполезная трата времени. Отлаживать нужно сразу исполняемый запрос. А ошибки удобно искать уже с помощью консоли запросов, безбоязненно удаляя ненужные временные таблицы.
4. Если ошибка возвращается от пользователя, то удобнее сразу смотреть исполняемый текст запроса по точке останова в конфигураторе.
А что из предложенного в статье принимать и пользоваться каждый должен определять для себя самостоятельно.
Категорически не согласна. Учить нужно тому как работает и почему. И исследования проводить, когда документация ответов на вопрос не дает. А определять, какими инструментами пользоваться, каждый должен решать самостоятельно. Главное, чтобы осознанно было.
Предлагаю сойтись на том, что на вкус и цвет все фломастеры разные. Автору нравятся собственные иллюстрации, с красивыми розовыми примечаниями. И не очень нравятся предлагаемые на замену (слишком много лишнего и раскраска цветом отвлекает от того, на что автор хочет обратить внимание).
Есть сомнения, что ИР позволят обойти проблему автоматического уменьшения широких скриншотов с существенным ухудшением четкости изображения на сайте. Но автор обязательно проверит - вдруг, они на самом деле волшебные!
Я бы подал как только один из подходов которым пользуются профессионалы, в том случае "когда я сел писать отчет и он никак не получался и тогда я стал вот так делать и туда смотреть и все получилось, всегда так буду делать", это было бы ближе людям и душевнее. А так не очень понятно в чем была проблема, если сам никогда не сталкивался.
И где-то у вас потерялась доля выпадающая на обработку информации. Проведение, закрытие месяца, куда их? Ну интеграцию еще можно во ввод добавить и то со скрипом. Тут тоже немножко обидели :)
Одно только "Как на такой «зубодробительной» терминологии можно нынешнее поколение стажеров, которые и слова-то такого страшного «Компоновка» не знают, обучать?!)" чего стоит.
Отчего Вы решили, что стажеры ничего не смыслят? Почему не допустить, что, возможно, они знают больше Вас? Черпают информацию с ИТС, например, там много чего полезного и, главное, правильного.
И эта категоричность, отчего Вы решили, что, например, в СКД, как Выпишете:
"Все очень просто – запрос, помещенный в схему компоновки данных, НИКОГДА НЕ ВЫПОЛНЯЕТСЯ."
Или это:
ВСЕ, ЧТО ВЫ ДОЛЖНЫ ИЗВЛЕЧЬ ДЛЯ СЕБЯ ИЗ ДАННОГО ПРИМЕРА – БЕСПОЛЕЗНО ОТЛАЖИВАТЬ В КОНСОЛИ ЗАПРОСОВ ИСХОДНЫЙ ЗАПРОС! ЗАЧЕМ ОТЛАЖИВАТЬ ТО, ЧТО НЕ ВЫПОЛНЯЕТСЯ?
Кто Вам это сказал?))
Я Вам покажу, что это не так.
Все зависит от того, что Вы хотите получить, зная как работает СКД.
В Вашем примере ключевой момент это "....Ссылка", когда Вы добавляете ее в запрос и потом в настройках выбираете, например, Наименование, то в запросе можно не указывать это поле, чтобы не было дублей в запросе СКД.
Это удобно, когда по ссылке пользователь может в пользовательском режиме добавлять в отчет дополнительные поля.
То, что у Вас Left Join в профайлере почему Вас так удивляет, запрос не распухает, это называется неявный вызов присоединеной таблицы, тут ничего удивительного нет(я уже не говорю об "СБ_ТранспортныеСредства.Модификация.Наименование").
Вообще, на ИТС по поводу СКД есть мысли почему так, запрос нужен для получения набора данных(с минимумом отборов), дальнейшие действия выполняются средствами СКД(поля, отбор и т.д.)
Теперь про запрос в наборе данных, который, как бы, не выполняется, и запрос на выходе в макете компоновки(не знаю Вашей конфигурации(хорошо было бы указать, впрочем, для проверки достаточно реквизита ссылочного типа в любом справочнике)):
Первый вариант, когда "жестко" задаем типы полей в запросе(без ссылок):
Если из-за пары незадокументированных приколов с прокидкой параметров в виртуальные таблицы автор предлагает отлаживать это в конфигураторе, то грошь цена автору, ведь суть оптимизации скд в том, чтобы конечный результат совпадал в тем, что изначально задан в скд в секции с текстом, однако делал это без лишних запросов в базу и без лишней нагрузки на субд
Когда я начал делать интеграции, то это стало 5-10%...
Поэтому с этим утверждением не согласен.
Кстати, кто-то видел хоть раз в типовых ЕРП/УХ-ах более-менее сложный отчет, сделанный полностью на СКД 1С-никами? Лично мне не попадались... А так хотелось вникнуть и в соединение между наборами данных, и в мистику вычислемых выражений, и в тайну построения собственных макетов... Потому как каждый раз с этим СКД - как в первый раз.
Советовать разрабам не начинать с отладки запроса в консоли я все-таки бы не спешил... В конце концов, консоль это не только про оптимизацию, а это про структуру, про корректность получаемых данных, лично я любой отчет начинаю с консоли и прежде чем класть запрос на СКД, с консультантом всегда отлаживаю ИМЕННО запрос... Данные получены, данные верны, запрос корректный - велком ту СКД.
СКД делает магию, это безусловно. Документации по нему в 1С минимум - факт медицинский. На поля во временных таблицах накладываются отборы когда нужно и когда не нужно - тоже факт.
То, что СКД мудит в виртуальных таблицах с условиями я замечал, но сейчас наконец-то я не один, и человек вот пожалуйста, системно расписал проблему)
Все же, слишком кардинальные рекомендации в статье... Я б не спешил с такими выводами. А вот встать точкой останова на скомпонованный макет, и открыть целевой запрос который пойдет в базу - мысль правильная и трезвая. Ну и опять же, в консольку его, в консольку)
Плюсанул.
ЗЫ: аффтор, не бойся критики - используй ее, как ресурс. Никто никогда ни в чем не прав на 100%, если это не исторический факт ("я съел котлету", хотя и тут придут те, кто скажет, что это была не котлета, а: зраза, бифштекс, шницель, ...)
очень спорное утверждение, ну попробуйте хотя бы в черновую накидать в конфигураторе запрос, в котором участвуют метаданные из основной конфигурации... и еще и 2-3-х расширений ... (ну такие вот отчеты тоже нужны бывают)...
Кроме того, я категорически против создания таблиц в БД за счет расширений. Недавно базу потеряла, причем на достаточно свежей платформе (к счастью, копию для разработки). Просто добавила по справочнику в два расширения и не сняла галку безопасный режим. Ни в конфигуратор, ни в пользовательский режим после этого войти не смогла. А т.к. БД была на PostgreSQL, то и восстановиться на момент времени до подключения расширений возможности не было (не продуктив же).
Опять проблема документации/информирования от 1С. Все клиенты хотят минимизировать расходы. В случае с расширениями - за счет обновлений. Сложился стереотип, что расширение - это универсальное решение проблемы. А об ограничения, рисках, и о том, что совсем не бесплатно( а, м.б., даже существенно дороже!), как-то информация замалчивается...
Всегда можно сказать нет))) И послать лесом или предложить переделать по-нормальному))
(110)
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 2513534
Создание 29.10.25 11:30
Обновление 12.11.25 08:39
Просмотры 27242
Загрузки 0
Рейтинг
117
Комментарии 112
Код открыт Да
Рубрики СКД
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)