Таблица Reference в 1С: назначение и структура данных

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

По сути, Reference — это не одна конкретная таблица в базе данных, а обобщающее понятие для механизма ссылок на объекты метаданных. В физической базе данных (MS SQL, PostgreSQL, Oracle) каждому справочнику или документу соответствует набор таблиц, где одна из них является таблицей ссылок (или таблицей заголовков). Именно здесь хранится уникальный идентификатор объекта, его код, наименование и основные реквизиты, по которым происходит быстрый поиск. Разработчикам необходимо четко различать логическую структуру метаданных и физическое представление данных в СУБД.

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

Архитектура хранения ссылок в базе данных

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

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

Важно отметить, что структура хранения может отличаться в зависимости от режима работы базы данных: файловый вариант (.1CD) или клиент-серверный (SQL). В файловом варианте все данные упакованы в один бинарный файл, и понятие отдельной таблицы Reference существует лишь логически внутри движка. В клиент-серверном варианте вы можете увидеть реальные таблицы черезатор баз данных, где они будут иметь имена вида _Reference123 или подобные, в зависимости от имени объекта метаданных.

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

Типы данных и работа со ссылками в коде

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

Одной из частых ошибок является попытка сравнить ссылки из разных справочников или приведение их к строковому виду для поиска. Хотя технически ссылка содержит уникальный идентификатор, платформа строго следит за типизацией. Прямое сравнение возможно только между ссылками одного типа метаданных. Для работы с универсальными коллекциями, такими как Массив или ТаблицаЗначений, часто требуется хранение ссылок в колонках с типом ХранилищеЗначения или специфическим типом Ссылка.

• 🔍 Пустая ссылка: Специальное значение, указывающее на отсутствие объекта; не путать с Null в SQL.
• 🆔 Уникальный идентификатор: Внутреннее представление ссылки в виде 16-байтовой строки (UUID), используемое в СУБД.
• 📂 Владелец: Атрибут ссылки, определяющий принадлежность объекта к родительской записи в иерархических справочниках.

При передаче параметров между клиентом и сервером ссылки сериализуются особым образом. Это обеспечивает целостность данных при распределенной архитектуре приложения. Если вы работаете с внешними источниками данных через ODBC или ADO, вам придется вручную преобразовывать строковые представления UUID в формат, понятный 1С, или наоборот. Это требует внимательности, так как форматирование UUID может различаться в разных операционных системах.

Особенности хранения UUID в разных СУБД

В MS SQL Server уникальный идентификатор хранится в типе данных UNIQUEIDENTIFIER. В PostgreSQL для этих целей часто используется тип UUID или BYTEA, в зависимости от версии платформы 1С и настроек кластера. Это важно учитывать при написании нативных SQL-запросов.

Анализ таблицы Reference через консоль запросов

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

Рассмотрим пример получения списка всех элементов справочника «Номенклатура» через прямой запрос к таблице ссылок. В зависимости от версии платформы и конфигурации, имя таблицы может выглядеть как _Reference15 или содержать полное имя объекта. Использование системных таблиц метаинформации, таких как _InfoRgSettings или аналогов, помогает динамически определять актуальные имена таблиц.

ВЫБРАТЬ
Ссылка.Ссылка КАК УникальныйID,
Ссылка.Код КАК Артикул,
Ссылка.Наименование КАК НазваниеТовара
ИЗ
Справочник.Номенклатура КАК Ссылка
ГДЕ
Ссылка.ЭтоГруппа = ЛОЖЬ

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

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

При анализе больших объемов данных важно использовать поля индексации. Обычно это поля _Order (для сортировки) и _KindRef (для определения типа ссылки в универсальных таблицах). Игнорирование индексов при написании тяжелых аналитических запросов может заблокировать работу базы для других пользователей из-за таблицых блокировок.

Особенности универсальных таблиц и видов ссылок

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

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

Тип объекта	Физическое поле в СУБД	Описание содержимого
Справочник	_Reference<ID>	Хранит код, наименование, владельца и флаг группы
Документ	_Document<ID>	Хранит номер, дату, время и ссылку на проведение
План счетов	_AccRg<ID>	Специфическая структура для бухгалтерских счетов
Бизнес-процесс	_BPR<ID>	Содержит состояние и точку маршрута процесса

Использование универсальных таблиц существенно экономит место в базе данных и упрощает структуру метаданных, но усложняет отладку. При просмотре такой таблицы в режиме предприятия вы увидите единый список, но при выгрузке в Excel или внешнюю систему данные могут потребовать дополнительной обработки для разделения по типам объектов. Это критично при настройке обмена данными через XML или JSON.

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

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

Регулярное обновление статистики по таблицам ссылок — обязательная процедура для администратора баз данных. В MS SQL Server это делается через стандартные планы обслуживания, в PostgreSQL — через VACUUM и ANALYZE. Если статистика устарела, оптимизатор запросов может выбрать неверный план выполнения, например, полный скан таблицы вместо поиска по индексу, что при миллионах записей приведет к зависанию системы.

• 🚀 Реиндексация: Процедура восстановления структуры индексов, устраняющая фрагментацию и ускоряющая поиск.
• 📉 Удаление помеченных объектов: Очистка таблиц от логически удаленных, но физически присутствующих записей.
• ⚙️ Настройка параметров СУБД: Корректировка объема оперативной памяти, выделяемой под кэш таблиц и индексов.

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

⚠️ Внимание: Интерфейсы и точные названия пунктов меню для обслуживания базы данных могут отличаться в зависимости от версии платформы 1С (8.2, 8.3, 8.3.20+) и конкретной конфигурации. Всегда сверяйтесь с официальной документацией к вашей версии перед выполнением операций обслуживания.

Миграция данных и восстановление ссылок

При переносе данных из одной информационной базы в другую (например, при обновлении типовой конфигурации или консолидации данных) ссылки являются самым уязвимым местом. Если в базе-приемнике отсутствует объект с таким же уникальным идентификатором, ссылка станет «битой». Платформа 1С предоставляет механизмы правил конвертации данных (КД 2.0, КД 3.0), которые автоматически решают проблему сопоставления ссылок.

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

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

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

Можно ли изменить уникальный идентификатор (UUID) существующего элемента справочника?

Нет, уникальный идентификатор присваивается объекту в момент его создания и не подлежит изменению стандартными средствами платформы. Это фундаментальное свойство обеспечивает неизменность ссылки на объект в течение всего его жизненного цикла. Попытка изменить UUID напрямую в базе данных через SQL приведет к потере связи со всеми зависимыми объектами (документами, регистрами).

Почему в SQL-таблице ссылок больше записей, чем элементов в справочнике 1С?

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

Как найти объект по его UUID, зная только идентификатор?

В консоли запросов или коде 1С можно использовать конструкцию Справочники.ВсеСсылки.НайтиПоСсылке(УникальныйИдентификатор), если тип объекта неизвестен, но это работает не во всех контекстах. Лучше использовать универсальный запрос с приведением типа или поиск по системным таблицам метаинформации, сопоставляя UUID с конкретным типом метаданных. В интерфейсе предприятия такой функции нет, требуется режим предприятия с отладкой или администрирование.

Влияет ли количество записей в таблице Reference на скорость запуска 1С?

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

Что такое таблица _Version в контексте ссылок?

Таблица _Version хранит информацию о версиях объектов конфигурации и иногда используется для отслеживания изменений в структуре метаданных, но не хранит сами ссылки на данные пользователей. Ссылки на объекты данных хранятся в таблицах _Reference..., _Document... и других, соответствующих типам метаданных. Путать эти системные таблицы не рекомендуется.