При работе с инструментом 1С:Аналитика разработчики часто сталкиваются с существенным ограничением: система не поддерживает использование временных таблиц (ВТ) в текстах запросов, используемых в качестве источников данных. Это создает серьезные трудности при попытке перенести сложные, оптимизированные отчеты из классической конфигурации 1С в интерфейс BI-анализа. В этой статье мы подробно разберем, как алгоритмически преобразовать пакетный запрос с ВТ в один массивный запрос с вложенными подзапросами, проанализируем технические риски и рассмотрим альтернативные архитектурные подходы.
Прежде чем переходить к конвертации, давайте разберем причину этого ограничения. 1С:Аналитика ориентирована на работу с Дата-акселератором (DBM) или прямые высокоскоростные запросы к СУБД для обеспечения мгновенного отклика при BI-анализе. Временные таблицы в 1С создаются в контексте сеанса пользователя в базе tempdb. Механизмы Аналитики и Акселератора часто работают в ином контексте или используют параллельную обработку, где доступ к «сеансовым» временным таблицам затруднен или невозможен. Кроме того, Акселератор данных строит собственные планы выполнения, которые лучше оптимизированы под «плоские» структуры данных.
Рассмотрим логику, по которой можно программно или вручную преобразовать пакетный запрос. Суть метода заключается в использовании «карты соответствий», где ключом является имя временной таблицы, а значением — текст запроса, который её наполняет. Разберем этот процесс по шагам:
Соответствие (или таблицу значений), где будем хранить пары «Имя ВТ» — «Текст запроса».ПОМЕСТИТЬ ВТ1. Берем текст запроса, который формирует эту таблицу, и записываем его в наше соответствие под ключом "ВТ1".ВТ2 выбирает данные из ВТ1, мы выполняем замену. В тексте запроса для ВТ2 находим упоминание ВТ1 и заменяем его на текст из нашего хранилища, обернутый в скобки.
Например, запрос:
ВЫБРАТЬ Поле1 ИЗ ВТ1 КАК ВТ1
превращается в:
ВЫБРАТЬ Поле1 ИЗ (ВЫБРАТЬ ... Текст запроса ВТ1 ...) КАК ВТ1
ВТ2 (уже содержащий в себе вложенный подзапрос ВТ1) сохраняем в соответствие.УНИЧТОЖИТЬ ВТ1, мы просто удаляем этот ключ из соответствия. Это позволяет корректно обрабатывать ситуации, когда в одном длинном пакете имя ВТ используется повторно для совершенно других данных.Проанализируем ситуацию глубже: простая текстовая замена может привести к неработоспособности запроса или катастрофическому падению производительности. Выделим критические моменты:
1. Потеря типизации полей. При использовании временных таблиц платформа 1С часто жестко типизирует колонки. Во вложенных запросах типы определяются динамически. Это может привести к ошибкам при сравнении ссылок разных типов или возникновению NULL там, где ожидалась пустая ссылка. Мы рекомендуем во всех подзапросах активно использовать функцию ВЫРАЗИТЬ(... КАК ...) для принудительного указания типов критически важных полей.
2. Проблема индексации. Это самый важный аспект. Временные таблицы позволяют использовать ключевое слово ИНДЕКСИРОВАТЬ ПО. Индексы позволяют СУБД мгновенно выполнять соединения (JOIN) таблиц. Вложенные подзапросы индексировать нельзя. Если ваш отчет оперирует сотнями тысяч строк, замена ВТ на вложенные запросы заставит СУБД выполнять соединения путем полного сканирования виртуальных таблиц, что увеличит время выполнения запроса с секунд до часов.
3. Дублирование кода и вычислений. Если одна и та же временная таблица ВТ_Контрагенты используется в пяти разных местах итогового запроса, то при конвертации её текст будет вставлен пять раз. СУБД может не распознать идентичность этих подзапросов и будет выполнять один и тот же расчет пять раз подряд, вместо того чтобы один раз прочитать данные из временной таблицы.
Если после конвертации запрос становится «монструозным» и перестает выполняться из-за ограничений СУБД на вложенность или длину текста, рассмотрим более надежный архитектурный путь. Вместо того чтобы «мучить» 1С:Аналитику сложными расчетами на лету, мы можем подготовить данные заранее.
Рассмотрим шаги по созданию «витрины данных»:
ВЫБРАТЬ * ИЗ РегистрВитринаДанных.Такой подход не только обходит ограничения на ВТ, но и значительно ускоряет работу пользователей в интерфейсе Аналитики, так как все тяжелые расчеты уже выполнены в фоновом режиме.
Проанализируем, какие инструменты могут помочь в автоматизации этого процесса. Если вы все же решили идти по пути генерации вложенных запросов, обратите внимание на Схему Компоновки Данных (СКД). Система компоновки при генерации итогового макета часто сама выполняет трансформации запросов. Можно попробовать программно извлечь итоговый текст запроса из исполняемого макета компоновки, однако будьте готовы к тому, что он будет содержать специфические конструкции, требующие дополнительной очистки.
Также полезно использовать консоли запросов с функцией развертки пакета. Хотя они выдают SQL-код, ориентированный на конкретную СУБД, логику построения вложенных конструкций можно заимствовать оттуда. Помните, что при ручной сборке важно соблюдать иерархию имен: каждому вложенному запросу должен быть назначен уникальный псевдоним, чтобы избежать конфликтов имен полей в итоговой выборке.
Выясним причину, по которой иногда стоит отказаться от полной автоматизации: если запрос содержит специфические конструкции АВТОУПОРЯДОЧИВАНИЕ или сложные соединения с таблицами значений, передаваемыми как параметры, простая замена текста не сработает. В таких случаях ручная переработка логики отчета под структуру «один запрос — один результат» является единственным стабильным решением.