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

← На главную

При работе с базами данных на платформе 1С:Предприятие многие разработчики, привыкшие к классическому проектированию в реляционных СУБД, сталкиваются с неожиданной особенностью. Открыв MS SQL Server Management Studio и попытавшись построить диаграмму базы данных, они обнаруживают полную изоляцию таблиц друг от друга. В этой статье мы подробно разберем, почему в 1С отсутствуют привычные внешние ключи (Foreign Keys), как на самом деле устроены отношения между данными и какими механизмами платформа обеспечивает целостность структуры.

Почему в SQL-таблицах 1С нет физических связей (Foreign Keys)?

Рассмотрим причины, по которым фирма «1С» отказалась от использования стандартных механизмов СУБД для организации связей. Основная причина заключается в обеспечении кроссплатформенности. Платформа 1С должна одинаково эффективно работать с MS SQL Server, PostgreSQL, IBM DB2 и Oracle Database. Реализация логики связей на уровне движка 1С позволяет абстрагироваться от специфических особенностей конкретной СУБД.

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

Анатомия связи: идентификаторы и ссылки

Выясним, как именно таблицы «понимают», что они связаны. В 1С любая ссылка на объект — это 128-битный уникальный идентификатор (GUID). В таблицах SQL эти идентификаторы хранятся в полях с типом binary(16). Разберем структуру типичного справочника и документа:

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

Проанализируем ситуацию на примере. Допустим, у нас есть справочник Контрагенты и документ РеализацияТоваровУслуг. В таблице документа будет колонка, хранящая идентификатор контрагента. На уровне SQL это выглядит как обычное поле с двоичными данными. Связь между ними существует только в «голове» сервера приложений 1С, который при выполнении запроса генерирует классический JOIN.

Сложные связи: составные типы данных

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

_TYPE — поле, определяющее категорию типа (число, строка, дата или ссылка).
_TRef — идентификатор метаданных таблицы (ссылка на конкретный тип объекта).
_RRef — непосредственно GUID записи в этой таблице.

Разберем по шагам, как платформа обрабатывает такой запрос. Когда мы обращаемся к реквизиту составного типа, движок 1С сначала анализирует поле _TRef, чтобы понять, к какой физической таблице SQL нужно обратиться, а затем использует _RRef для поиска конкретной строки.

Где хранится информация о структуре таблиц?

Если в SQL нет связей, то где-то должно быть описание того, как таблицы соотносятся друг с другом. Вся эта информация зашита в метаданных конфигурации. Рассмотрим основные системные таблицы, в которых хранятся эти «карты»:

Config — здесь хранится само дерево метаданных в сжатом виде. Это описание всех объектов, их реквизитов и связей, созданных в конфигураторе.
DBSchema — специальная таблица, хранящая структуру хранения данных. Именно здесь сопоставляются понятные нам имена (например, «Справочник.Номенклатура») с именами таблиц в SQL (например, _Reference45).
Params — содержит общие настройки базы и ссылки на структуры файлов внутри базы.

Для того чтобы программно получить это сопоставление, мы можем воспользоваться встроенным методом платформы. Посмотрим на пример кода:


СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Таблица Из СтруктураХранения Цикл
    Сообщить("Имя таблицы в 1С: " + Таблица.ИмяТаблицы);
    Сообщить("Имя таблицы в SQL: " + Таблица.ИмяТаблицыХранения);
КонецЦикла;

Контроль ссылочной целостности

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

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

Как построить ER-диаграмму для 1С?

Если вам все же необходимо визуализировать связи, встроенные средства SQL Management Studio вам не помогут напрямую. Рассмотрим альтернативные пути:

Использование внешних обработок. Существуют специализированные инструменты (например, «Структура конфигурации»), которые анализируют метаданные внутри 1С и строят графические схемы связей между объектами.
Парсинг DBSchema. Продвинутые разработчики используют скрипты для чтения двоичных данных из таблицы DBSchema, чтобы программно восстановить логику связей и передать её в инструменты визуализации типа ERWin или draw.io.
Технологический журнал. Проанализируем работу платформы через ТЖ: там можно увидеть реальные JOIN-запросы, которые строит движок. Это дает понимание того, как платформа связывает таблицы в реальном времени.

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