При разработке отчетов на базе Системы компоновки данных (СКД) начинающие разработчики часто сталкиваются с дилеммой: использовать вкладку Отборы или вкладку Параметры. На первый взгляд они выполняют схожую функцию — ограничивают набор данных, выводимых в отчет. Однако за этой внешней схожестью скрываются глубокие архитектурные и функциональные различия. В этой статье мы подробно разберем, как работают эти механизмы, проанализируем их влияние на производительность и выясним, в каких ситуациях следует отдавать предпочтение тому или иному инструменту.
Для начала определим базовую логику этих механизмов. Параметр — это своего рода «входная переменная» для всей схемы компоновки или конкретного набора данных. Без заполнения обязательного параметра отчет зачастую просто не сможет сформироваться. Отбор — это фильтр, который накладывается на уже описанную структуру данных.
Разберем это на классическом примере: Параметр — это условие получения результата (например, мы говорим системе: «дай мне данные за Октябрь»). Отбор — это фильтрация уже полученного результата (мы говорим: «из всех данных, что ты нашла, покажи мне только те, где склад равен Основному»).
Рассмотрим, как эти инструменты выглядят и ведут себя в руках конечного пользователя. Это один из важнейших критериев выбора для разработчика.
&Параметр = Поле).СтандартныйПериод. Это позволяет пользователю выбирать интервалы (Вчера, Текущий квартал, Прошлый год) одним нажатием кнопки, в то время как отбор по дате обычно заставляет выбирать конкретные границы вручную.Проанализируем техническую сторону вопроса. Одним из самых критичных отличий является то, как СКД транслирует условия в SQL-запрос, особенно при работе с виртуальными таблицами (Остатки, Обороты).
Рассмотрим ситуацию, когда нам нужно получить продажи за период. Если мы используем Параметры виртуальной таблицы, запрос будет выглядеть примерно так:
ВЫБРАТЬ
ПродажиОбороты.Номенклатура,
ПродажиОбороты.КоличествоОборот
ИЗ
РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, , ) КАК ПродажиОбороты
В этом случае СУБД сразу понимает, за какой интервал нужно рассчитать итоги. Если же мы откажемся от параметров и наложим Отбор по полю Период, система может сначала попытаться выбрать данные за всю историю регистра, а затем отсечь лишнее на уровне временных таблиц или финального результата. На больших объемах данных это приведет к катастрофическому падению скорости.
Важное правило: Для ограничения данных в виртуальных таблицах (даты, условия по измерениям для расчета остатков) всегда следует использовать параметры или механизм расширения языка запросов СКД.
Выясним, как сделать параметры такими же гибкими, как отборы. В СКД существует механизм фигурных скобок {}, который позволяет делать параметры необязательными. Рассмотрим пример кода в запросе:
ВЫБРАТЬ
Продажи.Номенклатура,
Продажи.Сумма
ИЗ
РегистрНакопления.Продажи КАК Продажи
ГДЕ
Продажи.Организация = &Организация
{ГДЕ
(Продажи.Склад = &Склад)}
В данном случае параметр &Организация является обязательным. Если пользователь не заполнит его, отчет выдаст ошибку. Однако условие по складу заключено в фигурные скобки. Если на вкладке «Параметры» пользователь снимет галочку использования со склада, СКД просто выбросит этот кусок из финального SQL-запроса, и данные будут получены по всем складам.
Разберем ситуации, когда отборы бессильны, и нам необходимы именно параметры. Параметры могут выступать не только как фильтры, но и как переменные для расчетов.
&КурсВалюты и использовать его в формуле вычисляемого поля: Сумма * &КурсВалюты. Отбор не может участвовать в арифметических операциях внутри схемы.Сумма > &ПорогРентабельности, то красим строку в красный цвет.Посмотрим на уровни применения настроек. Параметры в СКД практически всегда действуют глобально на весь набор данных. Отборы же обладают уникальной гибкостью иерархии:
Проанализируем итоговые рекомендации для выбора между двумя инструментами:
Выбирайте ПАРАМЕТР, если:
Выбирайте ОТБОР, если:
Таким образом, эффективное использование СКД предполагает комбинирование этих методов: использование параметров для оптимизации запросов и базовой логики, и отборов — для предоставления пользователю максимальной гибкости при анализе данных.