При работе с запросами в системе 1С:Предприятие, особенно в контексте Системы компоновки данных (СКД) или Построителя запросов, разработчики часто сталкиваются со специфическим синтаксисом: использованием фигурных скобок {} — для этого подойдёт консоль запросов и СКД для разработчиков.. Рассмотрим подробнее, что означает конструкция {ГДЕ ПланыПродаж.Номенклатура.*}, почему она критически важна для создания гибких отчетов и как она влияет на итоговое выполнение кода в базе данных.
Стандартный язык запросов 1С предназначен для жесткого описания выборки данных. Однако для отчетов требуется гибкость: пользователь должен иметь возможность сам решать, по каким полям накладывать фильтры. Если мы пропишем обычное условие ГДЕ, оно станет обязательным, и запрос не выполнится, если параметр не заполнен. Чтобы решить эту проблему, было введено расширение языка запросов.
Фрагмент кода, заключенный в фигурные скобки {}, представляет собой специальную инструкцию для платформы. Это не часть SQL-запроса в чистом виде, а «подсказка» для механизма компоновки данных. Рассмотрим, как это работает: если в настройках отчета пользователь не выбрал отбор по номенклатуре, платформа просто проигнорирует всё, что написано внутри {}, и выполнит запрос без лишних условий. Если же отбор установлен, платформа динамически «дорисует» реальную секцию ГДЕ в итоговом SQL-запросе.
Символ * (звездочка) после имени поля, например Номенклатура.*, играет ключевую роль в обеспечении доступности реквизитов объекта. Проанализируем разницу:
{ГДЕ ПланыПродаж.Номенклатура} (без звездочки), пользователь сможет установить отбор только по самой ссылке на справочник Номенклатура.Номенклатура.* разрешает устанавливать отборы не только по ссылке, но и по любым вложенным реквизитам этого объекта. Это могут быть Артикул, ВидНоменклатуры, СтавкаНДС и даже реквизиты более глубокого уровня вложенности.Таким образом, звездочка позволяет «развернуть» объект в интерфейсе настроек СКД, предоставляя пользователю пользовательской СКД полную свободу в фильтрации данных без необходимости для программиста вручную прописывать каждое возможное поле в тексте запроса. Для этой задачи есть выгрузка данных из СКД во внешние системы.
Выясним причину, по которой этот механизм считается более эффективным, чем ручное управление параметрами. Рассмотрим ситуацию на примере. Допустим, у нас есть следующий запрос:
ВЫБРАТЬ
ПланыПродаж.Номенклатура,
ПланыПродаж.Количество
ИЗ
РегистрСведений.ПланыПродаж КАК ПланыПродаж
{ГДЕ
ПланыПродаж.Номенклатура.*}
Посмотрим, что произойдет в разных сценариях работы пользователя:
Сценарий 1: Пользователь не установил никаких фильтров.
Платформа проигнорирует блок в фигурных скобках. В базу данных уйдет простейший запрос SELECT ... FROM ... без условий. Это обеспечивает максимальную производительность — для этого подойдёт оптимизация производительности сложных запросов 1С..
Сценарий 2: Пользователь установил отбор: Номенклатура.Артикул РАВНО "001".
Платформа автоматически трансформирует запрос. Она добавит внутреннее соединение (или коррелированный запрос) к таблице справочника Номенклатура и применит фильтр по полю Артикул. Текст запроса, который фактически уйдет на SQL-сервер, будет содержать полноценную секцию WHERE.
Помимо секции {ГДЕ ...}, в языке запросов для компоновки существуют и другие расширения, которые работают по аналогичным правилам. Разберем основные из них:
Хотя синтаксис фигурных скобок универсален, контекст их использования может отличаться. Проанализируем два основных механизма:
1. Построитель запросов (Query Builder): Это более старый механизм (часто встречается в «обычных формах» и типовых решениях прошлых поколений). Здесь расширения были основным и единственным способом сделать отчет гибким. Разработчик вручную прописывал эти блоки, чтобы ПостроительЗапросов знал, какие части текста можно изменять.
2. Система компоновки данных (СКД): В современном подходе на управляемых формах Конструктор запроса в СКД чаще всего сам генерирует эти скобки на закладке «Компоновка данных». Однако опытные разработчики часто редактируют их вручную. Например, это необходимо во вложенных запросах или объединениях (UNION), чтобы точно указать системе, на каком именно этапе вложенности нужно применить фильтр для оптимизации скорости работы.
Использование .* — это очень удобно, но требует осторожности в высоконагруженных системах. Разберем потенциальные риски. Если пользователь установит сложный отбор через несколько «точек» (например, Номенклатура.ОсновнойПоставщик.Регион.Код), СКД будет вынуждена добавить в итоговый запрос длинную цепочку LEFT JOIN. Если таблицы большие, а соответствующие поля не проиндексированы, это может привести к серьезным задержкам.
Практические советы (включая использование ИИ-помощника (поможет интеллектуальный помощник для написания кода 1С)) при написании таких запросов:
.*, а указать конкретное поле. Это сделает интерфейс настройки отчета чище.{ГДЕ ...}, видны пользователю в отборах, даже если они не выбраны в основном списке полей. Это отличный способ позволить фильтровать данные по служебным полям, которые не должны загромождать сам отчет и его схемы.Подводя итог, выражение {ГДЕ ПланыПродаж.Номенклатура.*} — это мощный инструмент 1С, превращающий статический запрос в динамический шаблон. Оно обеспечивает гибкость интерфейса и позволяет платформе автоматически оптимизировать SQL-код в зависимости от текущих потребностей пользователя.