Как узнать физическое имя таблицы справочника или документа 1С в базе данных SQL?

← На главную

При разработке интеграционных решений, прямом чтении данных или анализе производительности через профайлер СУБД разработчики часто сталкиваются с необходимостью сопоставить объект конфигурации 1С (например, Справочник.Номенклатура) с реальной таблицей в реляционной СУБД (такой как Microsoft SQL Server или PostgreSQL). В физической базе данных платформа 1С использует собственные технические идентификаторы вроде _Reference123 или _Document456. Разберем по шагам, как программно и с помощью системных средств выяснить имена таблиц и полей, а также разберем назначение служебных таблиц базы. Когда нужен список физических таблиц без написания вспомогательного кода, их можно посмотреть по объектам через обработку обследования метаданных. Для отображения имён выполняется расчёт нужного вида; на платформе 8.3 совместимость не подтверждена.

Использование штатной функции ПолучитьСтруктуруХраненияБазыДанных()

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

Рассмотрим синтаксис и параметры вызова данного метода:

ИменаМетаданных — массив имен метаданных или объектов метаданных. Если передать пустой массив или не указывать параметр вовсе, метод вернет описание структуры всей информационной базы. Однако на высоконагруженных конфигурациях (ERP, КА, УТ) это может занять существенное время и потребовать гигабайты оперативной памяти. Рекомендуется всегда явно передавать массив с целевыми объектами.
Поля — булево значение. Определяет, нужно ли выгружать детальную информацию по полям базы данных (колонки таблиц). По умолчанию принимает значение Истина. Если вам требуются исключительно имена самих таблиц, укажем Ложь — это в разы ускорит выполнение функции.

Посмотрим на практический пример кода, который возвращает реальное имя таблицы и структуру полей для справочника «Номенклатура»:


ОбъектыАнализа = Новый Массив;
ОбъектыАнализа.Добавить("Справочник.Номенклатура");

// Получаем структуру хранения для конкретного справочника
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(ОбъектыАнализа, Истина);

Для Каждого СтрокаТаблицы Из ТаблицаСтруктуры Цикл
    // ИмяТаблицыХранения содержит физическое имя таблицы в SQL
    Сообщить("Объект: " + СтрокаТаблицы.Имя + " | Имя в SQL: " + СтрокаТаблицы.ИмяТаблицыХранения + " | Назначение: " + СтрокаТаблицы.Назначение);
    
    // Перебираем поля таблицы хранения
    Для Каждого СтрокаПоля Из СтрокаТаблицы.Поля Цикл
        Сообщить("   Поле: " + СтрокаПоля.Имя + " -> Колонка в SQL: " + СтрокаПоля.ИмяПоляХранения);
    КонецЦикла;
КонецЦикла;

Принципы именования физических таблиц в СУБД

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

_Reference<Номер> — основная таблица справочника (например, _Reference120).
_Reference<Номер>_VT<Номер> — табличная часть справочника.
_ReferenceChngR<Номер> — таблица регистрации изменений справочника для планов обмена (РИБ).
_Document<Номер> и _Document<Номер>_VT<Номер> — документы и их табличные части.
_DocumentChngR<Номер> — таблица регистрации изменений документов.
_InfoReg<Номер> — регистры сведений.
_AccumReg<Номер>, _AccumRegTotals<Номер>, _AccumRegChange<Номер> — таблицы движений, итогов и доначислений регистров накопления.
_Fld<Номер> — пользовательские реквизиты объектов.

Системные реквизиты имеют постоянные имена во всех таблицах: _IDRRef (ссылка / GUID объекта), _Code (код элемента), _Description (наименование), _Marked (пометка на удаление), _Folder (признак группы).

Что такое таблица «Справочник.Номенклатура.Изменения»?

В результатах вызова ПолучитьСтруктуруХраненияБазыДанных() часто можно заметить таблицы вида Справочник.<Имя>.Изменения (в SQL это таблица с суффиксом ChngR). Проанализируем назначение этой таблицы.

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

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

Если нет возможности запустить режим «1С:Предприятие» в режиме отладки или выполнить код, разберем альтернативные инструменты:

Трассировка СУБД (SQL Server Profiler / Extended Events): запустим сбор трассировки, после чего в 1С откроем форму списка нужного справочника или запишем элемент. В окне профайлера перехватим SQL-выражения SELECT или UPDATE, содержащие реальные наименования таблиц и полей.
Технологический журнал 1С: настроим сбор событий группы DBMSSQL (или соответствующих вашей СУБД, например DBPOSTGRS). В сформированных логах будут присутствовать сгенерированные платформой запросы с точными именами задействованных таблиц.
Чтение системной таблицы PARAMS: полное соответствие метаданных и физических структур СУБД хранится в служебной таблице базы данных PARAMS в сжатом бинарном формате. Существуют готовые скрипты и утилиты, позволяющие десериализовать эти данные напрямую из SQL без запуска платформы.

Важные ограничения и риски

При работе с физическими таблицами напрямую через СУБД важно учитывать следующие особенности:

Непостоянство номеров объектов: числовой номер в названии таблицы (например, 125 в _Reference125) генерируется в момент создания объекта в конкретной базе данных. Если конфигурацию выгрузить в файл .cf и развернуть в новой базе, идентификаторы могут измениться. Жестко фиксировать эти имена в представлениях (SQL View), триггерах или внешних отчетах нельзя.
Реструктуризация: обновление конфигурации, удаление и повторное создание реквизитов способны привести к смене суффиксов полей _Fld<Номер>.
Ограничение на изменение данных: прямое выполнение инструкций INSERT, UPDATE, DELETE на уровне SQL запрещено лицензионным соглашением 1С. Это нарушает кэш платформы и приводит к рассогласованию ссылочной целостности базы. Допускается только операция чтения SELECT, при этом обязательно используйте уровень изоляции READ UNCOMMITTED (или подсказку WITH (NOLOCK)), чтобы предотвратить взаимоблокировки с транзакциями пользователей 1С.