Многие разработчики и администраторы 1С задаются вопросом о физическом расположении данных, с которыми они работают ежедневно. Когда вы формируете отчет или делаете выборку по остаткам товаров, система обращается к так называемым виртуальным таблицам. Однако, если открыть структуру базы данных на уровне СУБД (SQL Server или PostgreSQL), вы не найдете таблиц с именами вроде"РегистрНакопления.ОстаткиТоваров". Это вызывает недоумение: если таблицы нет, то где же лежат данные?
На самом деле, виртуальные таблицы — это не физические объекты хранения, а логическое представление данных. Они являются слоем абстракции, который платформа 1С:Предприятие накладывает на реальные физические таблицы регистров. Понимание этого механизма критически важно для оптимизации производительности и написания эффективных запросов.
В этой статье мы детально разберем архитектуру хранения данных в 1С, объясним принцип работы механизма виртуальных таблиц и покажем, как именно платформа транслирует ваши запросы в команды для СУБД. Вы поймете, почему прямое обращение к таблицам базы данных"в обход" 1С может привести к получению некорректных или неполных данных.
Физическая структура хранения данных в СУБД
Когда конфигурация 1С развертывается на сервере баз данных, платформа создает набор физических таблиц. Эти таблицы имеют специфические имена, часто состоящие из префикса _InfoRg (для регистров), _AccRg (для бухгалтерских регистров) или _Document. Именно в этих таблицах физически хранятся все записи, движения и срезы.
Виртуальная таблица, к которой вы обращаетесь в коде через конструкцию РегистрНакопления.Таблица.ВиртуальнаяТаблица, не имеет своего физического файла на диске сервера баз данных. Вместо этого она представляет собой сложный SQL-запрос (или представление — View), который динамически формируется платформой в момент выполнения.
Это означает, что данные не дублируются. Виртуальная таблица — это лишь"окно" или"линза", через которую мы смотрим на физические данные, применяя определенные фильтры и правила агрегации. Разработчик видит удобную структуру, а СУБД работает с оптимизированными табличными структурами.
⚠️ Внимание: Прямое чтение данных из физических таблиц СУБД (например, через SQL Management Studio) без учета служебных полей 1С (таких как
_Period,_RecorderRRef) часто приводит к неверной интерпретации остатков, так как вы видите сырые движения, а не рассчитанные срезы.
Рассмотрим пример соответствия имен. Если в конфигурации есть регистр накопления с именем ОстаткиТоваров, то в базе данных будет создана таблица _InfoRg12345 (где цифры — внутренний ID). Виртуальная таблица"Остатки" будет просто выборкой из этой физической таблицы с условием отбора по времени и измерениям.
При анализе медленных запросов всегда смотрите на план выполнения именно для сгенерированного SQL-запроса виртуальной таблицы, а не пытайтесь угадать структуру физических таблиц.
Механизм работы виртуальных таблиц регистров
Платформа 1С использует механизм виртуальных таблиц для упрощения работы с регистрами сведений, накопления и бухгалтерии. Основная задача этого механизма — скрыть от разработчика сложную логику расчета итогов и срезов. Когда вы пишете запрос к виртуальной таблице, платформа автоматически подставляет необходимые условия отбора и параметры периода.
Существует несколько основных типов виртуальных таблиц, каждый из которых имеет свою логику формирования данных:
- 📊 Периодические — выбирают данные на конкретный момент времени или за период (например,
ОстаткиИОбороты). - 📈 Агрегатные — используют предварительно рассчитанные итоговые таблицы для ускорения выборки больших объемов данных.
- 🔍 Срезы — возвращают последние записи по каждому сочетанию измерений на указанную дату (например,
СрезПоследних). - 📝 Движения — предоставляют доступ к необработанным записям о движениях регистров без агрегации.
Важно понимать, что при обращении к виртуальной таблице платформа генерирует SQL-код"на лету". Этот код может включать в себя объединения (UNION), подзапросы и временные таблицы, если это необходимо для корректного расчета. Например, виртуальная таблица Обороты должна просуммировать приход и расход за период, что требует группировки данных в физической таблице.
Как платформа определяет нужную физическую таблицу?
Платформа использует метаданные конфигурации, хранящиеся в таблице _v8MD, чтобы сопоставить имя объекта метаданных с именем физической таблицы в СУБД и сгенерировать корректный SQL.
Использование виртуальных таблиц гарантирует, что вы получите данные в соответствии с настройками регистра в конфигураторе. Если в регистре включено ведение итогов, запрос к виртуальной таблице остатков будет использовать таблицу итогов (_InfoRg12345T), что значительно ускоряет работу.
Различия между периодическими и неперодическими регистрами
Логика хранения и выборки данных существенно различается в зависимости от типа регистра. Для непериодических регистров сведений виртуальная таблица обычно представляет собой простой срез последних значений. Здесь нет привязки к времени в явном виде для каждой записи, если это не указано в измерениях.
В случае с периодическими регистрами (накопления, бухгалтерии, сведений с периодичностью), виртуальная таблица обязательно требует указания периода. Без параметра Между или На запрос к такой таблице часто невозможен или вернет все данные за всю историю, что недопустимо для производительности.
Рассмотрим ключевые отличия в поведении виртуальных таблиц:
| Характеристика | Периодический регистр | Непериодический регистр |
|---|---|---|
| Обязательный параметр | Период (Дата начала/конца) | Нет (или только условия отбора) |
| Физическая структура | Таблица движений + Таблица итогов | Единая таблица записей |
| Типичная виртуальная таблица | Остатки, Обороты, СрезПоследних | СрезПоследних |
| Зависимость от времени | Критическая (данные меняются во времени) | Минимальная (актуальное состояние) |
При разработке отчетов важно выбирать правильный тип виртуальной таблицы. Использование таблицы Движения для периодического регистра вместо Остатки заставит вас вручную писать логику суммирования, что не только сложно, но и медленно.
Оптимизация запросов через виртуальные таблицы
Одной из главных причин существования виртуальных таблиц является оптимизация. Платформа 1С знает о структуре индексов в физических таблицах лучше, чем средний разработчик. При формировании запроса к виртуальной таблице система старается использовать наиболее эффективные индексы СУБД.
Если вы попытаетесь реализовать аналог виртуальной таблицы вручную, написав сложный запрос к физическим таблицам, вы рискуете создать запрос, который не сможет воспользоваться существующими индексами. Это приведет к полному сканированию таблицы (Table Scan) и резкому падению производительности на больших базах данных.
Для максимальной эффективности следуйте этим рекомендациям:
- ⚡ Всегда указывайте отбор по периоду для периодических регистров, чтобы сузить область поиска.
- 🎯 Используйте отборы по ведущим измерениям в самом начале запроса для использования составных индексов.
- 🚫 Избегайте функций в условиях отбора по полям измерений, так как это отключает использование индексов.
Виртуальная таблица ОстаткиИОбороты является одним из самых мощных инструментов. Она позволяет получить сразу и начальный остаток, и обороты, и конечный остаток одним запросом. Внутренне платформа оптимизирует этот запрос, возможно, используя временные таблицы для промежуточных расчетов, но делает это максимально эффективно.
⚠️ Внимание: Интерфейс и возможности виртуальных таблиц могут незначительно отличаться в зависимости от версии платформы 1С и типа используемой СУБД (MS SQL, PostgreSQL, Oracle). Всегда проверяйте документацию для вашей конкретной версии.
Использование стандартных виртуальных таблиц гарантирует, что запрос будет выполнен с использованием оптимального плана выполнения, заранее предусмотренного разработчиками платформы.
Диагностика и анализ сгенерированных SQL-запросов
Иногда возникает необходимость понять, какой именно SQL-запрос генерирует платформа при обращении к виртуальной таблице. Это полезно для глубокой диагностики проблем производительности или для написанных внешних обработок, работающих напрямую с СУБД.
Узнать текст запроса можно несколькими способами. Самый простой — использовать режим отладки в Предприятии или специализированные инструменты мониторинга СУБД. В коде 1С можно вывести текст запроса через метод Запрос.Текст, но это покажет текст на языке 1С, а не нативный SQL.
Для получения нативного SQL-кода можно воспользоваться технологическим журналом (ТЖ) сервера 1С. Необходимо включить регистрацию событий категории DBMSSQL (или соответствующей вашей СУБД) с уровнем детализации info. В логах вы увидите полный текст запроса, уходящего в базу данных.
// Пример включения ТЖ для отладки запросов
// Файл rphost.xml в каталоге сервера
all
info
Анализируя полученный SQL, вы можете увидеть, как платформа преобразует виртуальную таблицу в набор JOIN и WHERE. Часто там встречаются служебные таблицы, такие как _Periods или таблицы параметров, которые обеспечивают корректную работу срезов.
☑️ Диагностика медленного запроса
Частые ошибки при работе с данными регистров
Непонимание природы виртуальных таблиц приводит к типичным ошибкам, которые сложно обнаружить на малых объемах данных, но которые становятся критичными на промышленных базах. Одна из самых распространенных ошибок — попытка получить"вчерашние" остатки без указания точного времени.
Виртуальная таблица СрезПоследних возвращает данные на конкретный момент времени. Если вы укажете дату без времени (например, 20.10.2023), система интерпретирует это как начало дня (00:00:00). Если движения были проведены в течение дня, вы получите остатки на начало дня, а не на конец.
Другая ошибка связана с игнорированием флагов"Ведение итогов". Если в регистре отключено ведение итогов, а вы делаете запрос к виртуальной таблице Остатки за большой период, платформа будет вынуждена сканировать всю таблицу движений и суммировать их в оперативной памяти или во временной таблице СУБД. Это может занять минуты или даже часы.
⚠️ Внимание: Никогда не полагайтесь на то, что виртуальная таблица"сама знает", что вам нужно. Всегда явно указывайте параметры периода и условия отбора по измерениям, чтобы избежать непреднамеренной выборки лишнего объема данных.
Также стоит помнить о блокировках. При записи в регистр могут устанавливаться блокировки на диапазоны данных. Чтение через виртуальную таблицу в момент интенсивной записи может привести к ожиданию снятия блокировок, если уровень изоляции транзакций настроен строго.
Почему запрос к остаткам работает медленно?
Чаще всего причина в отсутствии индекса по полям отбора или в том, что запрос вынужден рассчитывать остатки по всем движениям за длительный период из-за отсутствия итогов.
Где физически лежит таблица виртуального регистра?
Физически отдельной таблицы для виртуального представления не существует. Данные хранятся в физических таблицах регистра (движений и итогов), а виртуальная таблица — это динамически формируемый SQL-запрос (представление), который обращается к этим физическим данным.
Можно ли создать свою виртуальную таблицу?
В конфигураторе 1С вы не можете создать объект метаданных типа"Виртуальная таблица". Однако вы можете создать Представление (View) непосредственно в базе данных SQL, которое будет эмулировать, но платформа 1С не будет знать о его существовании как о стандартном объекте.
Зачем нужны параметры периода в виртуальных таблицах?
Параметры периода необходимы для ограничения выборки данными, актуальными на конкретный момент или за конкретный промежуток. Это критически важно для производительности, так как позволяет СУБД использовать индексы по полю периода и не сканировать всю историю изменений.
Влияет ли версия платформы на работу виртуальных таблиц?
Да, с выходом новых версий платформы 1С алгоритмы генерации SQL-запросов для виртуальных таблиц могут оптимизироваться. Также могут добавляться новые типы виртуальных таблиц или изменяться их поведение для повышения скорости работы.
Как узнать имя физической таблицы по имени регистра?
Имя физической таблицы можно узнать через консоль управления базой данных СУБД, посмотрев таблицы с префиксами _InfoRg, _AccRg и т.д., либо запросив метаданные через системные таблицы 1С, однако прямое сопоставление лучше делать через анализ технологического журнала.