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