В среде разработчиков 1С нередко возникают споры о целесообразности использования Системы компоновки данных (СКД). Некоторые специалисты, особенно те, кто начинал свой путь еще в эпоху 1С 7.7 или ранних версий 8.0, по привычке отдают предпочтение ручному написанию запросов, программному обходу результатов и заполнению областей макета. На первый взгляд кажется, что такой «ручной» подход дает полный контроль над процессом. Однако современные стандарты разработки диктуют иные правила. Разберем подробно, почему СКД — это не просто «конструктор для ленивых», а мощный аналитический движок, и в чем его реальные преимущества перед классическим программным выводом.
Рассмотрим стандартную ситуацию: вы написали отличный отчет через программный макет. Завтра к вам приходит пользователь (например, руководитель отдела продаж) и просит добавить еще один отбор, изменить группировку или вывести данные не по годам, а по месяцам. В случае с ручным макетом вам придется открывать конфигуратор, перерисовывать области, менять алгоритм обхода результата запроса и, возможно, создавать несколько вариантов одного и того же отчета.
Проанализируем возможности СКД в этом контексте. Система предоставляет пользователю «из коробки» следующие возможности:
Использование СистемыКомпоновкиДанных позволяет программисту один раз описать схему данных, а все дальнейшие вариации представления этих данных переложить на плечи (или желания) пользователей.
Выясним, что происходит «под капотом» при выполнении отчета. В программном коде вы пишете статический запрос. Даже если пользователю в данный момент нужны только две колонки из десяти, ваш запрос все равно выберет все данные и выполнит все соединения (JOIN), прописанные в тексте. Это создает лишнюю нагрузку на сервер СУБД.
СКД работает иначе. Она использует механизм динамической генерации текста запроса. Перед выполнением компоновщик анализирует настройки:
ВЫБРАТЬ.ЛЕВОЕ СОЕДИНЕНИЕ из итогового запроса к SQL.Такая оптимизация критически важна для высоконагруженных систем и отчетов по огромным таблицам данных.
Посмотрим на пример задачи: нужно рассчитать нарастающий итог или долю значения в группе. В обычном запросе для этого часто приходится использовать сложные соединения таблицы самой с собой, что сильно замедляет работу. В СКД для этих целей существуют Вычисляемые поля и специфические функции языка выражений компоновки данных.
Рассмотрим функцию ВычислитьВыражение(). Она позволяет обращаться к значениям других строк или группировок без повторного обращения к базе данных. Например, расчет доли продаж менеджера в общем объеме продаж отдела реализуется одной строкой в настройках СКД, в то время как в коде вам пришлось бы сначала вычислить общую сумму, а потом вторым проходом по таблице значений делить показатели каждого менеджера на этот итог.
Разберем ситуацию с «дырками» в данных. Если у вас нет продаж за 5-е число месяца, обычный запрос просто пропустит эту дату. Чтобы вывести красивый график с нулевыми значениями, в программном коде вам придется создавать вспомогательную таблицу дат и объединять ее с вашими данными.
В СКД достаточно назначить полю роль Период и настроить Дополнение периодов. Платформа сама сгенерирует недостающие строки в итоговом документе. Также роли полей позволяют корректно обрабатывать остатки и обороты (роль ОстаткиИОбороты), что избавляет от типичных ошибок «задвоения» итогов при левых соединениях таблиц с разной периодичностью.
Если ваша конфигурация построена на базе БиблиотекиСтандартныхПодсистем (БСП), то отчет на СКД автоматически получает огромный стек готовых функций:
Написание аналогичного функционала для ручного макета потребует сотен строк кода и значительных временных затрат на поддержку.
Несмотря на мощь СКД, проанализируем случаи, когда программный макет остается более эффективным:
Переход на использование СистемыКомпоновкиДанных — это переход от «рисования» конкретной картинки к проектированию модели данных. Мы рекомендуем использовать СКД для 95% задач по аналитической отчетности. Это повышает скорость разработки, надежность решения и, самое главное, дает пользователю ту гибкость, которую он ожидает от современной информационной системы. Программный код и ручные макеты лучше оставить для специфических печатных форм и сложных интерактивных интерфейсов.