Где хранятся дополнительные реквизиты в 1С 8.3

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

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

Механизм дополнительных реквизитов и сведений

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

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

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

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

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

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

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

• 📊 Таблицы планов видов характеристик содержат описания полей, а не сами значения данных.
• 🔗 Связь между значением и его описанием осуществляется через уникальный идентификатор ссылки.
• ⚙️ Изменение свойств реквизита в конфигураторе обновляет записи в соответствующем регистре характеристик.

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

Специфика хранения в документах и отчетах

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

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

⚠️ Внимание: При перепроведении документов значения дополнительных реквизитов могут быть перезаписаны или потеряны, если логика проведения не предусматривает их сохранение явно. Всегда проверяйте обработку проведения при использовании доп. полей.

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

Альтернативные способы: свойства объектов и расширения

Помимо стандартного механизма, существуют и другие способы хранения произвольных данных. Например, использование свойств объектов через механизм расширений или хранение данных в виде JSON/XML в одном текстовом поле. Такой подход часто применяется в интеграционных сценариях или при работе с веб-сервисами.

Хранение в формате JSON внутри одного поля типа «Строка» или «ХранениеДанных» позволяет избежать создания множества записей в регистрах. Однако это лишает возможности эффективно фильтровать данные средствами языка запросов 1С без предварительной обработки. Для поиска по таким данным требуется выгрузка в временные таблицы или использование внешних обработок.

ЗначениеВJSON = "{""Артикул"": ""12345"", ""Цвет"": ""Красный""}";
Объект.ДополнительныеДанные = ЗначениеВJSON;
Объект.Записать();

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

Почему JSON не всегда хорош для 1С?

Использование JSON усложняет индексацию и поиск. Платформа 1С оптимизирована для работы с типизированными данными в регистрах, а не с разбором текстовых строк на лету.

Технический анализ таблиц в SQL

Для глубокого понимания того, где физически лежат данные, необходимо обратиться к структуре таблиц в СУБД (MSSQL, PostgreSQL, Oracle). Имена таблиц формируются автоматически на основе имен объектов метаданных и часто содержат хеши или сокращения.

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

Объект метаданных	Тип таблицы SQL	Префикс таблицы	Назначение
Доп. реквизиты справочника	Регистр сведений	_InfoRg...	Хранение значений полей
План видов характеристик	Регистр сведений	_ChRg...	Описание видов реквизитов
Документ (поток данных)	Таблица потока	_DocumentFlow...	Связанные данные документов
Свойства объектов	Таблица свойств	_Obj...Props	Встроенные свойства

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

Оптимизация и частые ошибки разработчиков

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

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

⚠️ Внимание: Изменение конфигурации с добавлением новых полей в основные таблицы может потребовать длительной процедуры реструктуризации базы данных. Оценивайте риски перед переносом данных из доп. реквизитов в основные поля.

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

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

Можно ли программно создать новый дополнительный реквизит без конфигуратора?

Да, это возможно. Необходимо создать новую запись в соответствующем плане видов характеристик (например, ПланыВидовХарактеристик.ДополнительныеРеквизитыНоменклатуры). После создания вида реквизита его можно использовать для записи значений в регистр сведений.

Где найти таблицу с дополнительными реквизитами конкретного документа?

Имя таблицы зависит от имени объекта метаданных. Обычно это регистр сведений с именем вида ДополнительныеРеквизиты[ИмяОбъекта]. В SQL это будет таблица с префиксом _InfoRg и уникальным идентификатором. Точное имя можно узнать через консоль запросов или анализ структуры базы.

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

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

Как перенести данные из дополнительного реквизита в основное поле?

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

Хранятся ли дополнительные реквизиты в файловой базе 1С?

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