Откуда функция ПолучитьСтруктураХраненияБазыДанных() берет данные о таблицах SQL?

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

Основные источники данных о структуре

Для того чтобы понять, как формируется информация о структуре, нам необходимо рассмотреть три ключевых компонента в базе данных SQL, которые платформа использует для сборки итогового соответствия:

1. Таблица Config: Здесь хранится логическая структура конфигурации. Каждый объект метаданных описан в виде двоичных данных. Внутри этих данных зашит уникальный внутренний идентификатор (GUID) объекта. Именно этот GUID является "точкой сборки" для всех остальных связей.
2. Таблица Params (запись DBNames): В этой таблице существует строка с FileName = 'DBNames'. В ней в сжатом виде хранится словарь, сопоставляющий внутренние GUID объектов метаданных с именами таблиц в SQL. Например, запись говорит платформе, что объект с GUID abc-123... соответствует таблице _Document40.
3. Таблица DBSchema: Это описание физической схемы базы данных с точки зрения платформы 1С. Здесь зафиксированы поля таблиц, их типы и индексы. Если объект был создан и физически существует в базе, информация о нем обязательно будет присутствовать в DBSchema.

Проанализируем ситуацию: когда мы вызываем функцию ПолучитьСтруктураХраненияБазыДанных(), платформа не просто читает одну из этих таблиц. Она выполняет динамическую сборку данных, сопоставляя текущую конфигурацию из Config с картой имен из DBNames и проверяя реальность существования полей через DBSchema.

Почему прямая правка SQL не всегда дает результат

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

1. Кэширование на стороне сервера (rphost)

Платформа 1С крайне активно кэширует структуру метаданных. При первом обращении к структуре хранения в рамках сеанса или работы процесса rphost, данные вычитываются из SQL и помещаются в оперативную память сервера. При последующих вызовах функции обращения к SQL-таблицам Params или Config не происходит. Поэтому любые изменения, внесенные напрямую в СУБД "в обход" платформы, не будут видны до тех пор, пока не будет перезапущена служба сервера 1С или не будет выполнено действие, сбрасывающее кэш (например, обновление конфигурации базы данных).

2. Приоритет логической структуры

Посмотрим на алгоритм работы функции внимательнее. Если в таблице Config (логическая структура) объект существует, а в DBNames (словарь имен) вы его удалили прямой правкой, платформа может попытаться восстановить или использовать данные из DBSchema. Для корректного "скрытия" объекта пришлось бы синхронно модифицировать все три системные таблицы, что крайне опасно для целостности данных.

Практическое применение функции

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

ИменаОбъектов = Новый Массив;
ИменаОбъектов.Добавить("Документ.РеализацияТоваровУслуг");

СтруктураХранения = ПолучитьСтруктураХраненияБазыДанных(ИменаОбъектов);

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

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

Смещение дат и другие нюансы

Проанализируем еще один важный аспект. В таблице Params, помимо DBNames, хранится параметр _YearOffset. Он определяет смещение дат в SQL-базе (обычно это 2000 лет). Хотя этот параметр напрямую не влияет на имена таблиц, он критически важен для интерпретации содержимого этих таблиц. Функция ПолучитьСтруктураХраненияБазыДанных() учитывает эти настройки, чтобы корректно описывать типы полей.

Выводы и рекомендации

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

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

Таким образом, мы выяснили, что "магия" сопоставления имен — это многослойный процесс, завязанный на GUID-идентификаторах объектов, которые пронизывают всю структуру базы данных от логического уровня до физических таблиц.