Физическое место хранения дополнительных реквизитов в платформе 1С

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

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

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

Общая архитектура хранения произвольных данных

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

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

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

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

Хранение в табличных частях объектов

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

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

Рассмотрим основные колонки, которые обязательно присутствуют в такой служебной таблице:

• 📌 Ссылка — уникальная ссылка на родительский объект (справочник или документ), к которому относится значение.
• 📌 Свойство — ссылка на элемент плана видов характеристик, описывающий сам реквизит (его имя, тип, длину).
• 📌 Значение — универсальное поле типа ХранилищеЗначения или разбитое на типизированные поля в зависимости от версии платформы.
• 📌 ВерсияДанных — служебное поле для контроля целостности при параллельном редактировании.

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

Регистры сведений для планов видов характеристик

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

Таблицы регистров сведений для дополнительных сведений имеют префикс _InfoRg. Имя таблицы формируется на основе идентификатора регистра в базе данных. Внутри такой таблицы хранятся не только значения, но и описания самих свойств, если они вынесены в отдельный регистр. Это обеспечивает гибкость при изменении структуры данных без пересоздания таблиц.

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

ВЫБРАТЬ
ДополнительныеРеквизитыСсылка.Ссылка КАК Ссылка,
ДополнительныеРеквизитыСсылка.Свойство КАК Свойство,
ДополнительныеРеквизитыСсылка.Значение КАК Значение
ИЗ
Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДополнительныеРеквизитыСсылка

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

Особенности индексации

_Для ускорения выборки по дополнительным реквизитам платформа автоматически создает индексы по полям Ссылка и Свойство. Однако составные индексы, включающие поле Значение, не создаются автоматически и требуют ручной настройки через инструменты администрирования СУБД, если это критично для производительности.

Специфика хранения табличных частей дополнительных реквизитов

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

Значения таких реквизитов хранятся в отдельных служебных таблицах, связанных с основной таблицей дополнительных реквизитов через уникальный идентификатор строки. Фактически, создается трехуровневая иерархия: Объект -> Дополнительный Реквизит -> Строка Таблицы Значений. Это требует особой внимательности при проектировании схемы данных.

Ниже приведена таблица, описывающая соответствие типов значений и мест их физического хранения в базе данных:

Тип значения реквизита	Место хранения	Тип поля в SQL
Строка, Число, Дата	Табличная часть доп. реквизитов	VARCHAR, NUMERIC, DATETIME
Справочник, Документ	Табличная часть доп. реквизитов	_RRef (ссылка)
Булево	Табличная часть доп. реквизитов	BIT / BOOLEAN
Таблица значений	Отдельная вложенная таблица	Сложная структура
Хранилище значения	Табличная часть (серийная форма)	BLOB / VARBINARY

Использование типа ТаблицаЗначений в дополнительных реквизитах оправдано только в редких случаях, когда структура данных действительно динамична и не может быть предсказана на этапе проектирования. В остальных случаях рекомендуется выносить такие данные в отдельные регистры сведений для обеспечения лучшей производительности и удобства запросов.

⚠️ Внимание: Хранение больших объемов данных в дополнительных реквизитах типа «Таблица значений» может привести к значительному разрастанию базы данных и замедлению проведения документов. Рекомендуется ограничивать количество строк в таких таблицах.

Работа с хранилищем значений и сериализацией

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

Такой подход обеспечивает максимальную гибкость, но делает данные практически недоступными для анализа средствами SQL без использования функций платформы. При чтении такого реквизита через запрос 1С, система автоматически десериализует значение в объект языка. Однако использование таких реквизитов в условиях отбора (ГДЕ) может быть неэффективным.

Для оптимизации работы с сериализованными данными рекомендуется:

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

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

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

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

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

Еще одним методом оптимизации является использование временных таблиц при обработке больших массивов данных. Сначала выбираются необходимые ссылки объектов, а затем к ним присоединяются дополнительные реквизиты. Это уменьшает количество строк, участвующих в соединении, и ускоряет выполнение запроса.

Частые вопросы по хранению данных (FAQ)

Можно ли напрямую изменить значение дополнительного реквизита через SQL?

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

Где физически хранятся дополнительные реквизиты в файловой базе (.1CD)?

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

Влияет ли количество дополнительных реквизитов на скорость проведения документов?

Да, влияет. При проведении документа система может считывать и записывать значения дополнительных реквизитов. Если их много и они заполнены данными, объем операций ввода-вывода возрастает. Особенно заметно влияние при использовании реквизитов типа «Таблица значений» или «Хранилище значения».

Как найти все объекты, использующие конкретный дополнительный реквизит?

Для этого необходимо выполнить запрос к таблице дополнительных реквизитов с отбором по полю Свойство, указав нужную ссылку на план видов характеристик. Затем сгруппировать результаты по полю Таблица (если доступно в контексте) или анализировать ссылки для определения типа объекта.

Что произойдет с данными, если удалить свойство из плана видов характеристик?

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