Почему 1С:Фреш отклоняет запросы с обращением «через точку» к составным типам и как правильно оптимизировать код

← На главную

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

Техническая природа проблемы: механизм генерации SQL-запроса

Рассмотрим ситуацию, когда в запросе происходит обращение к полю ДокументОснование.Склад, где ДокументОснование имеет составной тип, включающий, например, 30 различных видов документов. Проанализируем, что происходит на уровне системы управления базами данных (СУБД). Платформа 1С для получения значения реквизита через точку вынуждена выполнить соединение (LEFT OUTER JOIN) со всеми таблицами, которые входят в этот составной тип.

Если в составной тип входит 30 типов документов, в итоговом SQL-запросе появится 30 дополнительных соединений. Это приводит к следующим последствиям:

Разрастание текста запроса: Текст запроса становится огромным, что само по себе увеличивает время его парсинга SQL-сервером.
Перегрузка оптимизатора СУБД: Оптимизатор планов запросов имеет ограничения по времени и ресурсам на поиск наиболее эффективного пути выполнения. При огромном количестве соединений он может «ошибиться» и выбрать неоптимальный план, что приведет к выполнению запроса в десятки и сотни раз дольше положенного.
Избыточное чтение данных: Даже если данные нужны только по одному конкретному типу, СУБД будет вынуждена проверять наличие записей во всех присоединенных таблицах.

Архитектура Multi-tenancy: почему это касается всех

Выясним причину, по которой админы 1С:Фреш не могут просто «добавить оперативной памяти» или ограничить ресурсы конкретного пользователя. В отличие от обычного облачного хостинга, где у каждого клиента своя база данных, 1С:Фреш работает по технологии Multi-tenancy (многоарендность).

В этой архитектуре тысячи организаций (областей данных) физически находятся в одной информационной базе SQL. Разделение данных происходит на программном уровне с помощью механизма Разделители данных. Это означает следующее:

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

Таким образом, аудит кода — это не «административная импотенция», а необходимый инструмент защиты стабильности сервиса для всех его клиентов.

Как правильно обращаться к реквизитам через точку

Рассмотрим, как изменить подход к написанию кода, чтобы соответствовать стандартам 1С и успешно проходить аудит. Основная задача — исключить неопределенность типов в запросе.

Способ 1: Использование функции ВЫРАЗИТЬ

Если мы заранее знаем, реквизиты какого именно типа документа нам нужны, мы должны явно указать это платформе. Разберем пример оптимизированного запроса:


ВЫБРАТЬ
    ВЫРАЗИТЬ(Источник.ДокументОснование КАК Документ.РеализацияТоваровУслуг).Склад КАК Склад,
    Источник.Ссылка КАК Ссылка
ИЗ
    Документ.МаркировкаТоваровИСМП КАК Источник
ГДЕ
    Источник.ДокументОснование ССЫЛКА Документ.РеализацияТоваровУслуг

В данном случае, благодаря использованию ВЫРАЗИТЬ, платформа создаст соединение только с одной таблицей Документ.РеализацияТоваровУслуг, что существенно снизит нагрузку на СУБД.

Способ 2: Использование временных таблиц и фильтрация по типам

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

Выбираем ссылки составного типа во временную таблицу.
Выполняем несколько отдельных запросов к этой временной таблице, в каждом из которых соединяемся только с одним конкретным типом через ВЫРАЗИТЬ.
Объединяем результаты через ОБЪЕДИНИТЬ ВСЕ.

Пример структуры такого запроса:


// Шаг 1: Отбор ссылок
ВЫБРАТЬ
    Т.ДокументОснование КАК СсылкаОснование
ПОМЕСТИТЬ ВТ_Основания
ИЗ
    Документ.МаркировкаТоваровИСМП КАК Т;

// Шаг 2: Выборка с типизацией
ВЫБРАТЬ
    ВЫРАЗИТЬ(ВТ.СсылкаОснование КАК Документ.РеализацияТоваровУслуг).Склад КАК Склад
ИЗ
    ВТ_Основания КАК ВТ
ГДЕ
    ВТ.СсылкаОснование ССЫЛКА Документ.РеализацияТоваровУслуг

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    ВЫРАЗИТЬ(ВТ.СсылкаОснование КАК Документ.ОтчетОРозничныхПродажах).Склад
ИЗ
    ВТ_Основания КАК ВТ
ГДЕ
    ВТ.СсылкаОснование ССЫЛКА Документ.ОтчетОРозничныхПродажах

Почему это важно для производительности

Посмотрим на реальные цифры. Как показывает практика эксплуатации крупных баз, один некорректный запрос к составному типу может загрузить 16-ядерный SQL-сервер на 100%. После исправления запроса с использованием явной типизации (через ВЫРАЗИТЬ или временные таблицы) нагрузка падает до 4-15%. Это критическая разница, которая определяет, будет ли сервис работать или «лежать».