Как реализовать универсальный фильтр в запросе 1С для работы с Неопределено, массивами и списками значений

В практике разработки на платформе 1С:Предприятие 8 часто возникает задача создания универсальных функций для получения данных. Основная сложность заключается в реализации гибких фильтров: когда параметр может быть не заполнен (равен Неопределено), содержать одну ссылку или целый массив/список значений. При этом мы хотим, чтобы запрос работал эффективно и корректно обрабатывал ситуацию, когда фильтр должен быть проигнорирован (выборка по всем записям).

В данной статье мы подробно разберем несколько подходов к решению этой задачи, проанализируем их плюсы и минусы, а также затронем вопросы производительности на уровне СУБД.

Вариант 1. Использование логических условий в тексте запроса

Рассмотрим наиболее изящный с точки зрения компактности кода способ, который позволяет передавать в один и тот же параметр как массив значений, так и литерал Неопределено. Проанализируем конструкцию, предложенную в обсуждении:

ГДЕ
    ВЫБОР
        КОГДА НЕОПРЕДЕЛЕНО В (&Контрагент)
            ТОГДА ИСТИНА
        ИНАЧЕ ФТ_Долги.Клиент В (&Контрагент)
    КОНЕЦ

Разберем по шагам, как это работает. Если в параметр &Контрагент передать массив, содержащий значение Неопределено, условие КОГДА сработает, и фильтр вернет ИСТИНА для всех строк таблицы. Если же передать массив со ссылками, сработает ветка ИНАЧЕ, где будет выполнена проверка на вхождение поля в список. Платформа 8.3 позволяет использовать оператор В даже для одиночных значений, автоматически преобразуя их в эффективное сравнение.

Важное замечание: такая конструкция может быть удобна для разработчика, но она не всегда оптимальна для планировщика запросов СУБД. Использование ВЫБОР внутри секции ГДЕ может помешать системе использовать индексы по полю Клиент.

Вариант 2. Классический метод с флагом-параметром

Рассмотрим более традиционный и «прозрачный» метод, который часто рекомендуют для обеспечения стабильной производительности. Мы вводим дополнительный булевый параметр, который сообщает запросу, нужно ли применять фильтр.

В тексте запроса это выглядит так:

ГДЕ
    (&ОтборОтключен ИЛИ ФТ_Долги.Клиент В (&Контрагент))

Теперь посмотрим на программную обвязку:

Если ЗначениеЗаполнено(Контрагент) Тогда
    Запрос.УстановитьПараметр("ОтборОтключен", Ложь);
    Запрос.УстановитьПараметр("Контрагент", Контрагент);
Иначе
    Запрос.УстановитьПараметр("ОтборОтключен", Истина);
    // Передаем пустой массив, чтобы избежать ошибки не заданного параметра
    Запрос.УстановитьПараметр("Контрагент", Новый Массив);
КонецЕсли;

Проанализируем ситуацию с точки зрения SQL. Современные версии платформы 1С и оптимизаторы MS SQL Server/PostgreSQL умеют обрабатывать такие конструкции (так называемый «Parameter Sniffing»). Однако на огромных таблицах условие ИЛИ может привести к полному сканированию таблицы (Index Scan) вместо поиска по индексу (Index Seek).

Вариант 3. Динамическое формирование текста запроса

Если производительность является критическим фактором, мы рекомендуем использовать динамическое изменение текста запроса. Это позволяет полностью исключить лишние условия из итогового SQL-запроса, отправляемого в СУБД.

Рассмотрим пример реализации с использованием подстановки через СтрЗаменить или шаблоны строк:

ТекстУсловия = "";
Если ЗначениеЗаполнено(Контрагент) Тогда
    ТекстУсловия = "И ФТ_Долги.Клиент В (&Контрагент)";
    Запрос.УстановитьПараметр("Контрагент", Контрагент);
КонецЕсли;

Запрос.Текст = СтрЗаменить(Запрос.Текст, "&ДополнительноеУсловие", ТекстУсловия);

Выясним причину, почему этот способ считается наиболее надежным для высоконагруженных систем:

1. Чистота SQL: В СУБД уходит максимально короткий и понятный запрос.
2. SARGability: Условия гарантированно позволяют использовать индексы, так как нет лишних логических операторов ИЛИ или ВЫБОР.
3. Отсутствие лишних параметров: Мы не передаем в запрос «пустые» массивы или флаги, которые только усложняют план выполнения.

Технические нюансы работы с типами данных

При реализации любого из вышеперечисленных методов необходимо учитывать особенности работы платформы 1С с типами NULL, НЕОПРЕДЕЛЕНО и пустыми коллекциями:

1. Пустой массив: Если вы передаете в оператор В (&Параметр) пустой массив, условие всегда будет ложным (ЛОЖЬ). Это важно помнить, так как если вы хотели «выбрать всё» при пустом массиве, без дополнительной логики запрос не вернет ни одной строки.
2. NULL vs НЕОПРЕДЕЛЕНО: Помните, что НЕОПРЕДЕЛЕНО — это значение конкретного типа, а NULL — это отсутствие значения (например, при левом соединении). Оператор В корректно работает с НЕОПРЕДЕЛЕНО, но для проверки на NULL необходимо использовать конструкцию ЕСТЬ NULL.
3. Составные типы: Если поле имеет составной тип, оно может физически содержать значение Неопределено. В этом случае проверка Клиент В (&Контрагент), где массив содержит Неопределено, отработает корректно и найдет такие записи.

Использование Схемы запроса для сложных задач

Для создания по-настоящему универсальных механизмов (например, в подсистемах отчетов) мы рекомендуем использовать объект СхемаЗапроса. Рассмотрим, почему это лучше простой замены строк:

• Программное добавление условий в СхемаЗапроса гарантирует, что вы не нарушите синтаксис запроса.
• Объект сам расставляет операторы ГДЕ и И, следя за структурой.
• Это избавляет от проблем, когда заменяемая подстрока (например, &Отбор) случайно встречается в комментариях или строковых литералах внутри запроса.

Подводя итог, можно сказать: для простых задач и небольших таблиц отлично подходит вариант с ВЫБОР или флаг-параметром. Однако для разработки универсальных инструментов в крупных базах данных следует отдавать предпочтение динамическому формированию текста запроса или работе со СхемаЗапроса, так как это гарантирует максимальную производительность на стороне сервера базы данных.