Как работает набор данных «Объединение» в СКД 1С и группирует ли он строки?

При разработке отчетов на базе Системы компоновки данных (СКД) в 1С программисты часто сталкиваются с дилеммой: объединить несколько таблиц-источников внутри одного SQL-запроса с помощью конструкции ОБЪЕДИНИТЬ ВСЕ или воспользоваться встроенным механизмом платформы — создать Набор данных — объединение. В этой статье мы подробно разберем особенности работы СКД-объединения, выясним, группирует ли этот механизм строки, и проанализируем, в каких ситуациях эффективнее использовать каждый из подходов.

Группирует ли строки набор данных «Объединение»?

Рассмотрим основной технический вопрос: происходит ли автоматическое сворачивание и устранение дублирующихся строк при слиянии данных через СКД-объединение? Ответ однозначен — нет, этот механизм не группирует строки самостоятельно.

По своей внутренней логике Набор данных — объединение работает абсолютно аналогично SQL-конструкции ОБЪЕДИНИТЬ ВСЕ (UNION ALL). Он просто последовательно выбирает записи из всех вложенных в него подчиненных наборов данных и объединяет их в один общий поток данных. Если в подчиненных наборах присутствуют абсолютно одинаковые строки, они в таком же виде (с дублями) попадут в итоговую выборку компоновки.

Выясним причину, почему разработчикам иногда кажется, что СКД производит группировку при объединении. Дело в том, что в Системе компоновки данных за разные этапы формирования отчета отвечают разные механизмы:

1. Этап получения данных: Наборы данных (запросы, объекты, объединения) отвечают исключительно за извлечение информации и передачу ее на следующий шаг. На этом этапе данные объединяются без группировки «как есть».
2. Этап компоновки и вывода: Сжатие, группировка, расчет итогов (ресурсов) и устранение дубликатов происходят позже — на уровне вкладки «Настройки» компоновки данных. Именно там мы задаем структуру отчета (группировки строк и колонок), и именно там платформа агрегирует данные согласно выбранным полям и ресурсам. Для сокращения времени на поиск расхождений после переноса данных или доработок можно автоматически сравнить бухгалтерские и налоговые проводки между базами.

Для подтверждения этого факта проведем простой эксперимент в консоли запросов или тестовом отчете. Если выполнить следующий запрос:

Выбрать 1 КАК Число, "Тест" КАК Строка
ОБЪЕДИНИТЬ ВСЕ
Выбрать 1, "Тест"

Мы получим две идентичные строки. Точно так же поведет себя и СКД с набором данных типа «Объединение», если в настройках структуры вывода мы укажем детальные записи без группировок и ресурсов. Для проверки работы подобных запросов и отчетов СКД можно использовать консоль запросов для отладки схем компоновки данных.

Ключевые отличия между СКД-объединением и UNION ALL в запросе

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

1. Объединение разнородных источников данных

В рамках классического запроса СУБД мы можем объединять только таблицы, хранящиеся в базе данных (или временные таблицы, созданные в ходе выполнения пакета). В СКД Набор данных — объединение позволяет комбинировать источники совершенно разной природы. Мы можем объединить в одно целое:

• Несколько разных наборов данных-запросов;
• Набор данных-запрос и набор данных-объект (например, внешнюю Таблицу значений, переданную в отчет из программного кода);
• Вложенные наборы-объединения.

2. Структурная гибкость и состав полей

При использовании конструкции ОБЪЕДИНИТЬ ВСЕ в обычном запросе действует жесткое правило СУБД: все объединяемые части обязаны иметь строго одинаковое количество колонок, а типы данных в соответствующих колонках должны быть совместимы. Разработчику приходится вручную выравнивать структуру, дописывая «пустые» поля:

ВЫБРАТЬ
    Продажи.Контрагент КАК Контрагент,
    Продажи.СуммаОборот КАК СуммаПродаж,
    0 КАК СуммаОстатка
ИЗ
    РегистрНакопления.Продажи.Обороты КАК Продажи

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    Взаиморасчеты.Контрагент,
    0,
    Взаиморасчеты.СуммаОстаток
ИЗ
    РегистрНакопления.Взаиморасчеты.Остатки КАК Взаиморасчеты

При работе с СКД-объединением этого делать не требуется. Подчиненные наборы данных могут иметь абсолютно разную структуру и произвольный набор полей. Платформа автоматически сопоставляет поля на основе их свойства «Путь к данным». Если в одном из наборов поле отсутствует, СКД сама подставит для него пустое значение или значение NULL во время компоновки результата.

3. Интеллектуальная работа с отборами

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

• Если пользователь устанавливает отбор по полю, которое присутствует во всех подчиненных запросах, СКД добавит этот отбор в условия ГДЕ каждой ветки.
• Если поле отбора присутствует только в одном из наборов, СКД применит фильтрацию исключительно к этому набору, не затрагивая остальные. В одном гигантском запросе с ручным объединением такую логику оптимизировать платформе значительно сложнее.

4. Индивидуальные параметры и автозаполнение

Каждая ветка внутри СКД-объединения (каждый подчиненный запрос) имеет свои собственные независимые настройки автозаполнения. Мы можем гибко управлять параметрами виртуальных таблиц в каждой ветке отдельно, что практически нереализуемо в рамках одного общего запроса с ОБЪЕДИНИТЬ ВСЕ.

Влияние на производительность: когда лучше переписать на единый запрос?

Несмотря на высокую гибкость СКД-объединения, при оптимизации «тяжелых» и долго выполняющихся отчетов часто прибегают к методу консолидации — переписывают структуру на один единый Набор данных — запрос с использованием конструкции ОБЪЕДИНИТЬ ВСЕ. Разберем по шагам, почему так происходит:

1. Обработка данных в оперативной памяти сервера 1С: При использовании СКД-объединения платформа выполняет к СУБД несколько отдельных изолированных запросов (по числу подчиненных наборов). Получив результаты от SQL-сервера, сервер приложений 1С начинает соединять и сопоставлять их в своей оперативной памяти. Если объем данных измеряется сотнями тысяч или миллионами строк, это приводит к колоссальной нагрузке на RAM сервера 1С и замедлению работы процесса.
2. Оптимизация на уровне СУБД: Когда мы передаем SQL-серверу один большой запрос с конструкцией ОБЪЕДИНИТЬ ВСЕ, планировщик СУБД строит единый оптимальный план выполнения. СУБД производит слияние данных на низком уровне гораздо быстрее и возвращает на сервер 1С уже готовый, оптимизированный поток данных.
3. Простота отладки в консоли запросов: Работать с одним запросом значительно проще. Его можно скопировать из схемы компоновки, вставить в Консоль запросов и быстро протестировать, проанализировать план выполнения или замерить время. Отлаживать сложное дерево наборов данных в СКД без специализированных инструментов крайне затруднительно.

Рекомендации по выбору архитектуры отчета

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

Используйте Набор данных — объединение, если:

• Вам необходимо объединить данные из базы 1С с внешними данными (например, с Таблицей значений, полученной из API, Excel или другого внешнего файла);
• У вас сильно различается состав полей в объединяемых частях, и вы не хотите загромождать код запросов многочисленными конструкциями вида ВЫБРАТЬ NULL КАК Поле;
• Вам требуется применять сложные, динамические отборы, которые должны по-разному отрабатывать в разных частях объединения.

Используйте единый Набор данных — запрос (с ОБЪЕДИНИТЬ ВСЕ), если:

• Вы разрабатываете высоконагруженный отчет, обрабатывающий большие массивы информации;
• Все объединяемые таблицы находятся в базе данных 1С;
• Для вас критически важна скорость формирования отчета и минимальное потребление оперативной памяти на сервере приложений 1С;
• Вам необходимо предварительно обработать объединенные данные во временных таблицах внутри того же пакета запросов перед их выводом в СКД.