_Reference в 1С: что это за таблица и как ей пользоваться

Когда база 1С развёрнута на Microsoft SQL Server или PostgreSQL, администратор, открывший список таблиц через Management Studio, обнаруживает сотни объектов с непонятными именами вида _Reference123, _Document456, _InfoRg789. Запрос «reference 1c что за таблица» — один из самых частых у тех, кто впервые столкнулся с физической структурой базы 1С на уровне СУБД.

Короткий ответ: таблицы с префиксом _Reference — это физическое хранилище справочников конфигурации 1С. Каждому справочнику, который вы видите в конфигураторе (Номенклатура, Контрагенты, Сотрудники и т.д.), соответствует одна таблица _ReferenceNNN в базе данных, где NNN — внутренний числовой идентификатор объекта метаданных.

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

Как устроена физическая структура базы 1С на SQL Server

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

Основные префиксы, которые встречаются в любой базе:

• _Reference — справочники (Номенклатура, Контрагенты, Склады);
• _Document — документы (Реализация товаров, Поступление, Приказ);
• _InfoRg — регистры сведений;
• _AccumRg — регистры накопления;
• _AccRg — регистры бухгалтерии;
• _Enum — перечисления;
• _Consts — константы;
• _Params, _Files, _Config — служебные и системные таблицы.

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

Какие поля есть внутри таблицы _Reference

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

Реквизиты, созданные в конфигураторе (ИНН, КПП, Артикул), хранятся в полях _FldNNN с тем же механизмом нумерации, что и сами таблицы. Соответствие номера поля конкретному реквизиту также определяется через структуру метаданных.

Табличные части справочника хранятся в отдельных таблицах вида _Reference123_VT456, где второй номер — идентификатор табличной части. Связь с основной таблицей осуществляется через поле ссылки на владельца строки.

Как узнать, какой справочник скрывается за номером таблицы

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

Способ 1: запрос к таблице соответствия

В большинстве конфигураций работает запрос к системной таблице, хранящей пары «идентификатор объекта — имя таблицы»:

SELECT TOP 50 * FROM _Reference22 -- пример: таблица соответствия объектов метаданных

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

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

Способ 2: через содержимое таблицы

Если доступа к конфигуратору нет, можно выполнить простой запрос SELECT TOP 10 _Code, _Description FROM _Reference123 и по наименованиям понять, что это за справочник. Коды и названия обычно однозначно указывают на содержимое: «ООО Ромашка» — контрагенты, артикулы — номенклатура, фамилии — сотрудники.

1. 1
   Откройте консоль запросов или внешнюю обработку в режиме Предприятия
2. 2
   Выполните ПолучитьСтруктуруХраненияБазыДанных() с фильтром по метаданным
3. 3
   Найдите нужный справочник и запомните имя его таблицы и полей
4. 4
   Проверьте результат простым SELECT по нескольким записям
5. 5
   Зафиксируйте соответствие в документации интеграции, но не зашивайте номера в код

Чем _Reference отличается от других таблиц платформы

Понимание различий между типами таблиц важно при построении прямых SQL-запросов: у каждого типа свой набор служебных полей и своя логика хранения.

Ключевое отличие справочников — отсутствие привязки ко времени и движениям. Это «плоский» список записей, на который ссылаются документы и регистры через поля типа _FldNNN_TYPE (тип), _FldNNN_RTRef (вид объекта) и _FldNNN_RRRef (сама ссылка) — так платформа хранит составные типы.

Безопасная работа с таблицами _Reference: что можно и что нельзя

Чтение данных напрямую из таблиц SQL — распространённая практика для интеграций, выгрузок в хранилища данных и тяжёлых аналитических отчётов. При соблюдении ряда правил это безопасно для целостности базы.

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

Дополнительные правила безопасного чтения:

• Используйте подсказку WITH (NOLOCK) или читайте из реплики, чтобы не создавать блокировки на рабочей базе;
• Учитывайте пометку удаления: фильтр _Marked = 0 отсекает помеченные элементы;
• Помните про разделители данных в режиме сервиса (SaaS) — в таблицах могут быть поля области данных;
• Не стройте логику на конкретных номерах таблиц — при обновлении конфигурации они могут измениться.

Практические сценарии использования

Выгрузка справочника во внешнюю систему

Типовая задача интеграции — забрать актуальный список контрагентов в CRM или BI-систему. Правильный подход: определить таблицу через структуру хранения, построить запрос с фильтром по пометке удаления и соединить пользовательские поля по их именам хранения.

SELECT r._IDRRef, r._Code, r._Description, f._Fld1001 AS INN
FROM _Reference123 r WITH (NOLOCK)
LEFT JOIN ... -- соединения по необходимости
WHERE r._Marked = 0

Поиск потерянного элемента

Если пользователь утверждает, что элемент справочника «исчез», проверка на уровне SQL показывает реальную картину: элемент может быть помечен на удаление (_Marked = 1), перенесён в другую группу или переименован. Запрос по коду или наименованию быстро проясняет ситуацию без перебора в интерфейсе.

Анализ дублей

Запрос с группировкой по наименованию или ИНН позволяет найти дубли элементов до запуска штатной обработки поиска и удаления дублей. Это безопасная read-only операция, которая помогает оценить масштаб проблемы.

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

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

Для разовой аналитики достаточно консоли запросов в режиме Предприятия. Для постоянной интеграции надёжнее опубликовать HTTP-сервис: он переживёт обновление конфигурации, тогда как SQL-скрипт с жёсткими номерами таблиц — нет.

Частые вопросы