Как правильно использовать параметры виртуальных таблиц и избежать ошибки VirtualTableCallWithoutParameters?

При разработке на платформе 1С:Предприятие 8 программисты часто сталкиваются с предупреждением статических анализаторов кода (например, BSL Language Server): «Обращение к виртуальной таблице без параметров» (VirtualTableCallWithoutParameters). На первый взгляд может показаться, что это лишь косметическое замечание, однако за ним стоят глубокие механизмы оптимизации работы СУБД и платформенные особенности хранения данных. Рассмотрим подробно, почему возникает эта ошибка, как она влияет на производительность и какими способами её можно устранить, сохранив правильную бизнес-логику.

Суть проблемы и работа оптимизатора запросов

Когда мы пишем запрос к виртуальной таблице, например, РегистрСведений.МойРегистр.СрезПоследних, платформа 1С транслирует этот вызов в сложный SQL-запрос. Виртуальная таблица не существует в базе данных в готовом виде (за исключением некоторых случаев с итогами), она формируется «на лету».

Проанализируем разницу в подходах фильтрации данных:

1. Фильтрация в параметрах виртуальной таблицы: Если условия (отборы) указаны непосредственно в скобках после имени таблицы, платформа включает эти условия во вложенный запрос SQL. Это позволяет СУБД сразу ограничить выборку данных на самом раннем этапе выполнения запроса.
2. Фильтрация в секции ГДЕ: Если параметры оставить пустыми, а условие написать в блоке ГДЕ, платформа сначала заставит СУБД построить виртуальную таблицу (часто для всех записей регистра), и только потом применит фильтр. Это приводит к избыточному чтению данных с диска, перерасходу оперативной памяти и существенному замедлению работы системы.

Рассмотрим пример кода, который вызывает диагностику ошибки:

ВЫБРАТЬ
    МойРегистр.Измерение КАК Измерение
ИЗ
    РегистрСведений.МойРегистр.СрезПоследних КАК МойРегистр
ГДЕ
    МойРегистр.Ресурс = &Ресурс

Для исправления этой ситуации, согласно стандартам, следует перенести условия в параметры виртуальной таблицы:

ВЫБРАТЬ
    МойРегистр.Измерение КАК Измерение
ИЗ
    РегистрСведений.МойРегистр.СрезПоследних(, Ресурс = &Ресурс) КАК МойРегистр

Механизм «Срез последних» и использование итогов

Важно понимать, что для регистров сведений в 1С существует специальная опция «Разрешить итоги: Срез последних». Рассмотрим, как это влияет на выбор между скоростью и чистотой кода.

Выясним причину, по которой иногда разработчики намеренно не указывают дату в параметрах. Если флаг итогов включен, платформа создает в СУБД отдельную физическую таблицу, где всегда хранится только актуальный срез на текущий момент.

Проанализируем две ситуации:

• Вызов СрезПоследних без параметра Даты: Платформа обращается напрямую к физической таблице итогов. Это самый быстрый способ, так как СУБД просто читает готовую запись.
• Вызов СрезПоследних с параметром Даты (даже если это ТекущаяДата): Платформа обязана гарантировать корректность данных на указанный момент. Она перестает использовать таблицу итогов и начинает выполнять поиск в основной таблице регистра, вычисляя максимальные даты для каждой комбинации измерений. Это работает значительно медленнее.

Таким образом, возникает дилемма: использовать параметр Период, чтобы соответствовать стандарту и застраховаться от будущих записей, или не использовать его ради максимальной производительности. Если ваша бизнес-логика гарантирует отсутствие записей «будущим числом», вызов без даты оправдан.

Особенности фильтрации по измерениям

Стандарт VirtualTableCallWithoutParameters требует передавать в параметры не только период, но и отборы по измерениям. Рассмотрим на примере поиска транспортного средства для водителя.

Если мы используем отбор в ГДЕ, СУБД может выполнить полное сканирование (Table Scan) всей таблицы актуальных записей. Если же мы передаем измерение в параметр, СУБД выполняет точечный поиск по индексу (Index Seek).

Правильный вариант вызова с точки зрения производительности и стандартов:

// В параметрах указываем пустую дату (для использования итогов) 
// и конкретное измерение для быстрого поиска по индексу
Запрос.Текст = 
"ВЫБРАТЬ
|   Регистр.ТранспортноеСредство
|ИЗ
|   РегистрСведений.ЗакреплениеВодителей.СрезПоследних(, Водитель = &Водитель) КАК Регистр";

Бизнес-логика и проблема «пустых» данных

В ходе обсуждения часто возникает вопрос: что делать, если нужно вернуть пустой результат, если последняя запись в регистре означает «снятие» объекта (например, водитель больше не числится за машиной)?

Разберем ситуацию: если мы добавим условие в параметры СрезПоследних(, Водитель = &Водитель И ТранспортноеСредство <> ЗНАЧЕНИЕ(Справочник.ТранспортныеСредства.ПустаяСсылка)), то запрос может вернуть предыдущую запись, где машина была указана, хотя последняя запись была пустой. Это логическая ошибка.

Правильный подход к решению такой задачи:

1. Получить срез последних только по измерению (Водитель).
2. Проанализировать полученный результат в коде или с помощью условий в запросе уже после получения среза.

Когда допустимо игнорировать ошибку?

Рассмотрим исключения, когда проверку анализатора можно и нужно подавить:

• Массовая выборка: Если вам действительно нужно получить текущий срез последних по всем записям регистра (например, для построения отчета или выгрузки в другую базу), параметры отбора по измерениям будут излишни.
• Архитектурные ограничения: В некоторых типовых конфигурациях (например, БП 3.0) разработчики сознательно не используют параметры в старых запросах, чтобы не вызвать регрессию производительности на огромных объемах данных.

Для подавления предупреждения в BSL Language Server используйте специальные комментарии:

// BSLLS:VirtualTableCallWithoutParameters-off
Результат = Запрос.Выполнить();
// BSLLS:VirtualTableCallWithoutParameters-on

Итоговые рекомендации

Подведем итог нашему анализу и сформулируем правила работы с виртуальными таблицами:

1. Всегда передавайте измерения: Если вы ищете данные по конкретному объекту (Водитель, Склад, Номенклатура), передавайте этот отбор в первый доступный параметр виртуальной таблицы. Это критично для скорости.
2. Определитесь с датой: Если нужны данные «на сейчас» и важна скорость — оставляйте параметр даты пустым (но будьте готовы к риску появления записей будущим числом). Если нужна точность на момент времени (например, дата документа) — передавайте дату обязательно.
3. Не путайте параметры и ГДЕ: Помните, что условия в параметрах влияют на состав виртуальной таблицы, а условия в ГДЕ — на фильтрацию уже готового результата.
4. Используйте функции повторного использования: Если запрос к срезу последних выполняется очень часто (например, при изменении реквизитов на форме), оберните его в функцию общего модуля с кэшированием (Повторное использование возвращаемых значений).

Соблюдение этих правил позволит вам писать не только «чистый» код, соответствующий стандартам, но и создавать высокопроизводительные решения, которые будут стабильно работать даже на крупных базах данных.