Что такое таблица _InfoRg в 1С: устройство регистров сведений

Разработчики и администраторы баз данных 1С:Предприятие часто сталкиваются с необходимостью прямого анализа физической структуры базы данных, особенно при решении сложных проблем производительности или написании специфических SQL-отчетов. В этом контексте возникает вопрос о назначении таблиц с префиксом _InfoRg. Эти объекты являются физическим представлением регистров сведений в реляционной СУБД, такой как MSSQL, PostgreSQL или Oracle. Понимание их устройства критически важно для тех, кто хочет выйти за рамки стандартного языка запросов платформы.

Таблица _InfoRg хранит срезы информации, не привязанные жестко к движению ресурсов, в отличие от регистров накопления. Она представляет собой плоскую структуру, оптимизированную для быстрого получения актуального состояния объектов на конкретный момент времени. Если вы работаете с большими объемами данных, знание внутренней архитектуры этих таблиц позволит вам писать более эффективные запросы и избегать блокировок, которые могут замедлить работу всей системы в часы пик.

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

Архитектура и физическое хранение данных

Физически таблица _InfoRg представляет собой набор колонок, строго соответствующих структуре метаданных в конфигураторе. Каждая запись в такой таблице уникально идентифицируется набором измерений, которые формируют первичный ключ. Важно понимать, что платформа автоматически управляет этими ключами, однако при написании прямых SQL-запросов вы должны учитывать порядок колонок для правильного использования индексов.

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

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

⚠️ Внимание: Прямое изменение данных в таблицах _InfoRg через SQL-клиент минушь механизмы платформы 1С может привести к рассинхронизации итогов, нарушению ссылочной целостности и невозможности проведения документов. Используйте такие методы только для чтения или аварийного восстановления под контролем опытного администратора.

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

Структура полей и типы данных

Каждая колонка в таблице _InfoRg соответствует определенному реквизиту регистра сведений. Измерения обычно располагаются в начале таблицы и имеют типы данных, соответствующие их назначению: целочисленные ссылки на таблицы справочников (_IDRRef), строки фиксированной длины или типы UUID. Ресурсы и дополнительные реквизиты следуют за измерениями.

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

Ниже приведена примерная структура типовой таблицы регистра сведений с периодичностью «В пределах дня»:

Имя поля (SQL)	Тип данных	Описание
_Period	DateTime	Дата и время записи среза
_RecordKind	SmallInt	Тип записи (активная/удаленная)
_IDRRef_Номенклатура	Binary(16)	Ссылка на элемент справочника
_Fld1234	Decimal	Ресурс числового типа
_Fld5678	Varchar	Текстовый реквизит

Как расшифровать имена полей _FldXXXX?

Имена полей вида _FldXXXX генерируются платформой автоматически. Число соответствует внутреннему UUID реквизита. Чтобы узнать соответствие, нужно открыть конфигуратор, посмотреть свойства реквизита или использовать таблицу _FieldNames в служебных данных 1С.

Типы данных ресурсов могут варьироваться от простых чисел до сложных структур, таких как Хранилище значения. В последнем случае данные могут быть сериализованы в бинарный формат, что делает их нечитаемыми для прямого SQL-анализа без специальной десериализации. Поэтому для сложных типов предпочтительнее использовать встроенные средства 1С.

Особенности работы с периодическими регистрами

Периодические регистры сведений предназначены для хранения истории изменения атрибутов объектов. Классическим примером является регистр «Цены номенклатуры», где цена одного и того же товара может меняться многократно в течение года. Таблица _InfoRg в этом случае растет линейно с добавлением новых записей, а не обновляет старые.

При выборке данных из таких таблиц критически важно правильно фильтровать записи по периоду. Если вы просто выберете все записи, вы получите дубликаты по измерениям с разными датами. Для получения актуальной цены на конкретную дату необходимо использовать логику «Срез последних». В SQL это реализуется через подзапросы или оконные функции.

• 📅 Точность времени: В 1С период часто включает время до секунд. При сравнении дат в SQL учитывайте этот нюанс, чтобы не потерять нужные записи из-за разницы в миллисекундах.
• 🔄 Записи движения: Некоторые конфигурации используют регистры сведений для хранения истории изменений (кто и когда поменял значение). В этом случае таблица работает как журнал аудита.
• 🗑️ Удаление помеченных: Физическое удаление записей из таблицы происходит только при выполнении процедуры «Удаление помеченных объектов». До этого момента удаленные записи могут оставаться в таблице со специальным флагом.

Оптимизация запросов к периодическим регистрам требует наличия правильных индексов. Платформа 1С автоматически создает индексы по основным измерениям и периоду. Однако, если вы часто фильтруете данные по ресурсам (например, «найти все товары с ценой выше 1000»), стандартных индексов может быть недостаточно, и потребуется настройка дополнительных индексов в метаданных.

Индексация и производительность выборок

Скорость работы с таблицами _InfoRg напрямую зависит от качества индексации. По умолчанию система создает кластерный индекс, обеспечивающий быструю выборку по измерениям и периоду. Однако в высоконагруженных системах, где объем записей исчисляется миллионами, даже небольшая неоптимальность запроса может привести к полному сканированию таблицы (Table Scan), что недопустимо.

Анализ планов выполнения запросов показывает, что наиболее «тяжелыми» операциями являются соединения таблиц по полям, не входящим в состав индекса, или использование функций в условиях WHERE, которые блокируют использование индекса. Например, применение функции CONVERT к полю даты в условии соединения может привести к деградации производительности на порядки.

⚠️ Внимание: Интерфейсы и алгоритмы работы СУБД могут обновляться разработчиками платформ и баз данных. Детали реализации индексов и планов выполнения могут отличаться в зависимости от версии 1С:Предприятие и конкретной версии MS SQL или PostgreSQL. Всегда проверяйте актуальные рекомендации в официальной документации ИТС или на портале разработчиков.

Для ускорения выборок по нерегулярным полям (реквизитам) рекомендуется использовать механизм «Ведущего типа» или создавать дополнительные индексы в свойствах регистра сведений. Это позволит базе данных строить более эффективные пути доступа к данным без необходимости перебора всех строк.

Также стоит упомянуть о проблеме фрагментации индексов. При активной вставке и удалении записей в периодические регистры индексы могут фрагментироваться, что снижает скорость чтения. Регулярная перестройка (REBUILD) или реорганизация (REORGANIZE) индексов является обязательной частью технического обслуживания базы данных 1С.

Прямые SQL-запросы и ограничения платформы

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

При написании таких запросов необходимо помнить о блокировках. 1С использует механизм управляемых блокировок, который может конфликтовать с прямыми SQL-транзакциями. Неверно выставленный уровень изоляции транзакции может привести к взаимоблокировкам (Deadlock), когда пользователи массово получат сообщения об ошибке записи.

Рассмотрим пример простого запроса для получения актуальной цены без использования механизмов 1С (псевдокод):

SELECT TOP 1 T._Fld1234
FROM _InfoRgPrices AS T
WHERE T._IDRRef_Product = @ProductID
AND T._Period <= @CurrentDate
ORDER BY T._Period DESC

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

Типичные ошибки и методы отладки

Одной из самых распространенных ошибок при работе с таблицами _InfoRg является игнорирование типа записи. В таблицах могут присутствовать записи, помеченные на удаление, которые все еще физически существуют. Если не фильтровать их по полю _RecordKind (где активные записи обычно имеют значение 0), отчеты могут показывать некорректные данные, включая уже удаленные объекты.

Еще одна проблема — некорректная обработка ссылок. Разработчики часто пытаются соединять таблицы по текстовому представлению ссылки (наименованию), что является грубой ошибкой. Соединение должно выполняться строго по уникальному идентификатору (_IDRRef). Использование имен объектов в условиях JOIN делает запрос крайне неэффективным и зависимым от языковых настроек базы.

• ❌ Игнорирование версионности: Попытка читать данные из таблиц без учета версии платформы может привести к ошибкам, если структура таблиц изменилась после обновления конфигурации.
• ⚠️ Отсутствие транзакционности: Выполнение серии SQL-запросов без явного начала и завершения транзакции может оставить базу данных в промежуточном, противоречивом состоянии в случае сбоя.
• 🔍 Неверная кодировка: При работе с текстовыми полями через внешние инструменты важно учитывать кодировку базы данных (UTF-8, CP1251), чтобы избежать появления «кракозябр» в отчетах.

Для отладки сложных ситуаций рекомендуется использовать журнал регистрации 1С в сочетании с профилировщиком SQL. Это позволяет увидеть, какой именно запрос 1С генерирует для работы с регистром сведений, и сравнить его с вашим ручным аналогом. Часто оказывается, что платформа использует временные таблицы для оптимизации, о чем начинающие разработчики не догадываются.

FAQ: Часто задаваемые вопросы

Можно ли добавлять новые поля в таблицу _InfoRg вручную через SQL?

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

Почему таблица _InfoRg занимает так много места на диске?

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

Как найти имя физической таблицы для конкретного регистра сведений?

Имя таблицы обычно формируется как _InfoRg плюс синоним или имя регистра в нижнем регистре. Точное соответствие можно узнать, посмотрев свойства объекта в конфигураторе (вкладка «Основное») или выполнив запрос к системным таблицам СУБД, отфильтровав их по префиксу.

Безопасно ли делать UPDATE в таблице _InfoRg для исправления ошибки?

Крайне рискованно. Прямое обновление может нарушить служебные связи, индексы и логику работы триггеров 1С. Безопаснее создать документ-корректировку или использовать обработку, написанную на языке 1С, которая выполнит изменение через стандартный механизм записи данных.