Как хранятся макеты и метаданные 1С в базе данных SQL

При изучении внутреннего устройства платформы 1С:Предприятие у разработчиков нередко возникает вопрос: как именно объекты конфигурации — например, созданный общий табличный документ — представлены на уровне таблиц реляционной СУБД (Microsoft SQL Server, PostgreSQL и др.). Разберем по шагам архитектуру хранения метаданных, структуру системных таблиц и механизмы упаковки бинарных данных платформы.

В каких таблицах SQL хранятся метаданные конфигурации

В отличие от прикладных данных (справочников, документов и регистров), для которых платформа 1С создает отдельные реляционные таблицы с префиксами _Reference, _Document или _InfoRg, конфигурация не разбивается на классические таблицы по типам метаданных. Метаданные хранятся в специальных системных таблицах в виде виртуальной файловой системы (контейнера):

1. Config — основная таблица, содержащая конфигурацию базы данных, с которой работает режим «1С:Предприятие».
2. ConfigSave — таблица рабочей конфигурации, в которую записываются изменения при сохранении в конфигураторе до выполнения команды обновления конфигурации базы данных (по нажатию F7).
3. Params — системные параметры информационной базы, включающие сведения о версиях метаданных, настройках и служебных структурах.

Проанализируем структуру самой таблицы Config. Она предельно проста и состоит из двух основных колонок:

1. FileName — строковое имя файла или идентификатор потока (часто представляет собой UUID объекта или служебное имя, например, root).
2. BinaryData — бинарное поле большого объема (тип VARBINARY(MAX) или IMAGE в MS SQL Server, BYTEA в PostgreSQL).

Как общий макет упакован внутри таблицы Config

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

1. Сжатие данных: Все бинарные блоки в поле BinaryData хранятся в сжатом виде с использованием алгоритма Deflate (библиотека zlib).
2. Дерево метаданных: В записи со служебным именем root содержится оглавление конфигурации. В нем описаны все объекты метаданных и сопоставленные им уникальные идентификаторы (UUID).
3. Данные макета: Для каждого общего макета формируются отдельные записи с именами вида <UUID> и дополнительными подпотоками. Внутри этих блоков после распаковки находится внутренняя структура описания макета и сам сериализованный табличный документ.

Внутри распакованного потока макет представляет собой либо внутренний текстовый формат 1С (древовидную структуру с разделителями в виде фигурных скобок {...}), либо бинарный поток объекта SpreadsheetDocument, содержащий информацию о ячейках, шрифтах, объединениях, линиях и графических объектах.

Порядок низкоуровневого поиска макета в SQL

Если требуется проследить путь поиска макета на уровне базы данных, разберем последовательность действий, которую выполняет платформа:

1. Из таблицы Config считывается и распаковывается корневой поток метаданных root.
2. В иерархии метаданных по имени общего макета находится его уникальный идентификатор UUID.
3. Выполняется SQL-запрос к таблице Config для получения записи, где в поле FileName указан соответствующий идентификатор.
4. Поле BinaryData извлекается и декомпрессируется библиотекой zlib, после чего объект восстанавливается в оперативной памяти сервера приложений 1С.

Безопасные и штатные альтернативы анализу таблиц СУБД

Важное предостережение: Любые попытки прямого редактирования записей в таблицах Config, ConfigSave или Params через прямые SQL-инструкции UPDATE, INSERT или DELETE категорически не рекомендуются. Платформа строго контролирует целостность кэша и контрольные суммы метаданных. Несогласованное изменение данных в SQL приведет к разрушению структуры базы и невозможности открыть конфигуратор.

Для исследования структуры макетов и работы с ними на низком уровне используем безопасные платформенные инструменты:

1. Выгрузка конфигурации в файлы: Штатная возможность выгрузки конфигурации в исходные коды (формат XML/EDT) позволяет увидеть полное текстовое и XML-представление макетов без прямого чтения системных таблиц СУБД.
2. Программный доступ через встроенный язык: Для получения макета и работы с его структурой из кода 1С используется стандартный механизм платформы.

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

// Получаем общий табличный документ по имени метаданных
МакетТаблицы = ПолучитьОбщийМакет("ИмяМоегоМакета");

// Проверяем тип полученного макета и выполняем его вывод
Если ТипЗнч(МакетТаблицы) = Тип("ТабличныйДокумент") Тогда
    ОбластьШапка = МакетТаблицы.ПолучитьОбласть("Шапка");
    // Дальнейшая работа с областями макета
КонецЕсли;

Таким образом, платформа 1С полностью инкапсулирует структуру метаданных внутри сжатых BLOB-хранилищ таблиц Config и ConfigSave, предоставляя разработчику высокоуровневый объектный интерфейс для безопасного доступа к элементам конфигурации.