Начнем
Часто ли Вы сталкиваетесь с критериями отбора при разработке? По себе могу сказать, что за 10 лет р
аботы с платформой у меня было не больше одного или двух десятков задач, в которых бы приходилось бы задействовать этот объект конфигурации.
Чаще всего это задачи, связанные с добавлением нетиповых документов в структуру подчиненности, ту самую типовую форму в конфигурациях. Реже - добавление какой-либо особой логики в механизм отображения подчиненности или что-нибудь специфическое.
Сами по себе критерии отбора не представляют из себя что-то сложное, но т.к. используются они на стадии конфигурирования довольно редко, то многие разработчики просто с ними не сталкиваются и не видят необходимости что-то про них узнавать.
Сегодня в статье мы начнем с простейшего примера работы с критерием отбора и в конце рассмотрим, как ведет себя платформа 1С на уровне СУБД. Матерые разработчики вряд ли найдут что-то новое. Но если Вы еще не погружались в принципы работы этого механизма, то можете найти что-то новое.
Исходный код всех примеров Вы можете найти в репозитории на GitHub.
Для чего они нужны?
Для чего нужны критерии отбора? Использование этого объекта конфигурации позволяет с относительной простотой получать для какого-либо объекта другие связанные объекты в информационной базе. При этом лишь необходимо настроить связь объектов в составе критерия отбора, а также указать доступные типы данных в реквизитах, по которым будет осуществляться связь.
Решим простую задачу. В тестовой конфигурации у нас есть три документа: "Заказ", "Приходный ордер" и "Расходный ордер". Приходный ордер создается на основании заявки, расходный на основании приходного ордера.
В каждом документе есть табличная часть "Список номенклатуры" с реквизитами "Номенклатура" и "Количество". Под номенклатурой понимается ссылка на элемент справочника "Товары". Количество - числовое значение.
Задача состоит в реализации механизма, позволяющего просматривать из формы документа введенные на его основании другие документы. А в элементе справочника "Товары" смотреть все документы, в которых товар использовался. Другими словами, нам нужна структура подчиненности.
Описание сумбурное и не совсем понятно, что вообще происходит? Вы можете посмотреть исходный код конфигурации с примером из публикации в репозитории.
И так, приступим к выполнению задачи.
Настроим критерий отбора и формы документов
Создадим критерий отбора в конфигураторе. Первым делом установим доступные типы значения отбора. Для этого перейдем на закладку "Данные" и включим в состав доступных типов следующие (см. след. скриншот).
В соответствии с установленными типами будет определен состав реквизитов у объектов конфигурации, по которым будет настраиваться связь между ними. Для настройки связей перейдем на вкладку "Состав" и установим следующие настройки:
С этими настройками мы можем, например, из документа "Приходный ордер" получить список всех документов "Расходный ордер", введенных на его основании. Также мы можем открыв элемент справочника "Товары" получить список всех документов, где есть ссылка на этот элемент. Чтобы такая возможность присутствовала в режиме предприятия нам необходимо добавить вызов формы критерия отбора из формы соответствующего элемента. Для этого, например, в форме документа "Заявка" установим галочку для отображения параметризируемой команды "Связанные элементы" из панели навигации (см. след. скриншот).
После всех вышеописанных действий посмотрим результаты в режиме 1С:Предприятия.
В пользовательском режиме
В информационной базе уже есть некоторые данные. Откроем документ "Заявка" и перейдем в список "Связанные документы".
Проделаем те же действия для элемента справочника "Товары". Результат будет следующим:
Таким образом, из элементов информационной базы (документов, справочников и т.д.) мы можем получать связанные с ними объекты.
Простой пример закончен
Критерии отбора используются практически во всех конфигурациях тиражных решений от фирмы "1С". На основе данного механизма построена возможность получения структуры подчиненности документов. Взгляните как раньше это выглядело в УПП. В современных конфигурациях все работает практически также.
В запросах можно обращаться к виртуальной таблице критерия отбора, передав туда ссылку на элемент информационной базы, для которого необходимо получить зависимые элементы. Результат запроса вернет ссылки на все элементы, в которых используется данный объект по настройками состава критерия отбора.
Таким образом, рассматриваемый объект конфигурации позволяет упростить решения задач по получению связанных элементов информационной базы. Иначе бы нам пришлось самостоятельно писать запросы и условия в них для каждого отдельного объекта в конфигурации.
Копнем глубже
Выше был рассмотрен простой пример настройки и использования объекта конфигурации "критерий отбора". Подробнее узнать информацию о нем Вы можете в синтаксис-помощнике или на официальном сайте.
Теперь давайте рассмотрим закулисную работу платформы 1С с базой данных при их использовании.
Что у нас есть?
В тестовой конфигурации содержатся три документа и справочник, связанные между собой следующим образом:
Также добавлен критерий отбора "СвязанныеЭлементы", настройки типов данных которого представлены на следующем скриншоте:
В его состав включены следующие объекты с реквизитами, выбранными в соответствии со связями между объектами метаданных.
В результате мы можем просматривать список связанных объектов информационной базы для каждого объекта, включенного в состав критерия отбора. Например, так будет выглядеть список всех документов, в которых используется текущий элемент справочника "Товары".
Критерии отбора возможно использовать в запросах.
В запросе
Для каждого критерия отбора становится доступной виртуальная таблица, в которой имеется единственный параметр "Значение". В параметр передается ссылка на элемент, для которого нужно получить связанные элементы.
При выполнении запроса мы получим аналогичный результат, что и на скриншоте выше, если в качестве параметра передадим ссылку на элемент справочника товары.
"За кулисами"
Сразу стоит оговориться, что отдельной SQL-таблицы для критерия отбора не создается. Платформа получает данные динамически, формирую SQL-запрос в зависимости от настроек критерия отбора.
Например, если мы выполним следующий запрос с ссылкой на элемент справочника "Товары" в параметре:
то платформа сформирует следующий SQL-запрос к СУБД:
На скриншоте подробно рассмотрен SQL-запрос, формируемый платформой. Наш пример усложнен тем, что для элемента справочника "Товары" ищутся документы по наличию ссылки на этот товар в их табличных частях. Поэтому в SQL-запросе присутствует конструкция "EXIST" для проверки наличия хотя бы одной ссылки на тов
ар в табличной части документа.
Для каждой таблицы документа формируется отдельный SELECT. После результаты объединяются с помощью конструкции "UNION ALL". Из полученной таблицы во вложенном запросе получают все ссылки на документы, в табличных частях которых присутствует искомый элемент справочника.
При создании критерия отбора, как уже говорилось выше, никаких отдельных таблиц в структуре информационной базы не создается. Но некоторые изменения в структуре базы все же имеются. Для реквизитов, используемых в критерии отбора, создается индекс для тех полей, которые используются для формирования связей. Поэтому обязательно стоит иметь ввиду, что наличие в конфигурации критериев отбора приводит к дополнительным расходам для обслуживания индексов.
Подобные SQL-запросы платформа формирует для всех случаев использования критерия отбора в конфигурации.
Интересности про индексы
Еще есть интересный момент, связанный с индексами. В конфигурации с примером для документа "Приходный ордер" в состав критерия отбора включен реквизит "Заявка". В базе данных по этому полю платформа создает простой индекс.
Как Вы думаете, что будет, если для реквизита документа явно установить свойство "Индексировать" в значение (внезапно) "Индексировать"?
Ответ на этот вопрос под спойлером. Попробуйте узнать правильный ответ. О результатах можно написать в комментариях :)
Не в качестве рекламы, просто рекомендую попробовать инструмент "Просмотр и анализ структуры базы данных (отчет на СКД)", чтобы погрузиться во "внутренности" работы платформы с СУБД. Отчет постепенно развивается, и Вы можете предложить свои варианты / вопросы по этому поводу.
Это еще не конец
Таким образом, критерий отбора - это механизм платформы, который выступает в качестве инструкции платформе для формирования SQL-запросов к базе данных на получения ссылок на связанные объекты информационной базы. В противном случае разработчику пришлось бы самостоятельно писать такие запросы и настраивать индексы для реквизитов объектов.
В типовых конфигурация критерий отбора используется, например, для получения структуры подчиненности документа.
Влияние на производительность с их стороны относительно незначительная. Из-за создания дополнительных индексов может увеличиться время записи, так как появляется необходимость в обновлении индекса при помещении данных в информационную базу. Также эти индексы потребляют дополнительное место на диске.
В любом случае, при правильном подходе этот объект имеет больше плюсов, чем минусов. Используйте разумно. И проверьте, не формируете ли Вы структуру подчиненности собственными запросами?
