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