Как узнать, какая таблица 1С соответствует таблице в SQL

Любой объект конфигурации 1С — справочник, документ, регистр сведений — физически хранится в базе данных SQL Server в виде таблиц с техническими именами вида _Reference123 или _Document456. Чтобы написать прямой SQL-запрос, проанализировать блокировки или выполнить обслуживание базы, нужно знать, какая именно таблица соответствует конкретному объекту метаданных.

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

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

Зачем вообще знать соответствие таблиц 1С и SQL

Прямой доступ к таблицам SQL требуется в нескольких типовых ситуациях. Первая — анализ производительности: при расследовании блокировок и длинных запросов в SQL Server Profiler или Extended Events фигурируют имена физических таблиц, и без расшифровки непонятно, какой объект 1С тормозит систему. Вторая — интеграционные задачи, когда сторонняя система читает данные напрямую из базы. Третья — выборочное обслуживание: перестроение индексов или обновление статистики по конкретным «тяжёлым» таблицам.

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

Способ 1: функция ПолучитьСтруктуруХраненияБазыДанных

Штатный и самый точный метод — встроенная функция платформы ПолучитьСтруктуруХраненияБазыДанных() (в английском синтаксисе — GetDBStorageStructureInfo()). Она возвращает таблицу значений, где для каждого объекта метаданных указаны имена физических таблиц и полей в СУБД.

Чтобы получить структуру, откройте базу в режиме тонкого клиента, запустите внешнюю обработку или консоль кода и выполните функцию без параметров — тогда вернётся полная структура всей конфигурации. Если нужен один конкретный объект, передайте в параметре массив с именами метаданных, например {"Справочник.Номенклатура"} — так результат формируется быстрее на больших конфигурациях.

Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из Структура Цикл
    Если Строка.ИмяТаблицыХранения <> "" Тогда
        Сообщить(Строка.Метаданные + " -> " + Строка.ИмяТаблицыХранения);
    КонецЕсли;
КонецЦикла;

В результате важны три колонки: Метаданные (полное имя объекта, например «Документ.РеализацияТоваровУслуг»), ИмяТаблицы (назначение таблицы) и ИмяТаблицыХранения (физическое имя в SQL, например _Document231). Именно связка «Метаданные → ИмяТаблицыХранения» даёт ответ на вопрос, какая таблица SQL соответствует объекту.

1. 1
   Откройте базу в тонком клиенте под пользователем с правами администратора
2. 2
   Запустите консоль кода или внешнюю обработку с вызовом ПолучитьСтруктуруХраненияБазыДанных()
3. 3
   Найдите в результате строку с нужным объектом метаданных
4. 4
   Скопируйте значение колонки ИмяТаблицыХранения — это имя таблицы в SQL Server
5. 5
   Проверьте результат запросом SELECT TOP 10 в SQL Server Management Studio

Способ 2: готовые внешние обработки

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

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

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

Способ 3: поиск через служебную таблицу Params

Когда доступа к тонкому клиенту нет, а есть только доступ к SQL Server, соответствие можно извлечь из самой базы. Платформа 1С хранит сериализованную структуру метаданных в служебных таблицах, в частности в таблице Params, где в одном из полей содержится описание соответствия имён в двоичном формате.

Прямой разбор двоичных данных — задача трудоёмкая, поэтому на практике чаще используют косвенный признак: у каждой таблицы справочника есть поле _IDRRef (ссылка), у документа — _IDRRef и _Number, у регистра сведений — поля измерений. Комбинируя состав полей с известными данными (например, выполнив SELECT по известному значению из 1С), можно идентифицировать таблицу перебором.

-- Поиск таблицы по известному значению: пример для SQL Server
-- Сначала смотрим список таблиц и их размер
SELECT t.name AS TableName, p.rows AS RowCount
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE p.index_id IN (0,1)
ORDER BY p.rows DESC;

Метод через Params стоит считать запасным: он медленнее, требует прав на чтение системных представлений и не даёт гарантированной расшифровки без дополнительных инструментов. По возможности всегда предпочитайте штатную функцию платформы.

Особенности: регистры, табличные части и итоги

Один объект метаданных почти никогда не равен одной таблице SQL. У документа, помимо основной таблицы _DocumentN, есть отдельная таблица на каждую табличную часть (_DocumentN_VTxxx) и таблица движений по каждому регистру, где он является регистратором. У справочника с табличными частями картина аналогичная.

Регистры накопления и сведений хранятся в таблицах вида _AccumRgN и _InfoRgN. Для регистров накопления существуют дополнительные служебные таблицы итогов (с суффиксами вида _AccumRgTnN и подобными), которые платформа использует для быстрого получения остатков. При анализе производительности важно различать основную таблицу движений и таблицы итогов — запросы к остаткам идут именно по итоговым таблицам.

Константы хранятся не по одной таблице на объект, а все вместе в единой таблице _Consts (с таблицей изменений _ConstsChngR при наличии планов обмена). Это частый источник путаницы при поиске «таблицы константы» — отдельной таблицы у неё нет.

Как проверить, что таблица найдена правильно

После того как имя получено, результат стоит верифицировать. Самый простой способ — выполнить в SQL Server Management Studio запрос SELECT TOP 10 * FROM _DocumentN и сопоставить содержимое с данными, видимыми в 1С: номера документов, даты, представления ссылок. Для справочника удобно искать по полю наименования.

Дополнительная проверка — по количеству записей. Если в 1С в справочнике «Номенклатура» около ста тысяч элементов, а в найденной таблице три строки, значит, это не та таблица (или вы смотрите не ту базу — проверьте, что подключены к рабочей, а не к тестовой копии).

Типичные ошибки при поиске таблиц

Отдельно стоит предупредить об изменении структуры при реструктуризации. При добавлении или удалении реквизитов платформа пересоздаёт таблицы, но имена таблиц при этом обычно сохраняются. А вот при удалении и повторном создании объекта метаданных (не переименовании, а именно удалении и создании нового) ему будет присвоено новое физическое имя — старые заметки о соответствии устареют.

FAQ: частые вопросы о таблицах 1С в SQL