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

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

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

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

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

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

Ключевым элементом архитектуры является таблица _InfoRgДополнительныеРеквизиты. Именно здесь концентрируется основная масса информации о пользовательских свойствах. Однако, важно понимать, что физическое имя таблицы в базе данных (SQL) может отличаться от логического имени в конфигураторе из-за префиксов и хеширования.

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

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

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

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

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

Технические детали именования таблиц

В физической базе данных SQL имя таблицы регистра будет выглядеть примерно как _InfoRg12345, где цифры — это уникальный идентификатор метаданных. Точное соответствие можно узнать через таблицу системных метаданных _v80metadata.

Особое внимание следует уделить типу хранимого значения. Поскольку в одной колонке могут храниться данные разных типов (строки, числа, даты, ссылки), используется механизм вариантных типов или отдельные колонки для каждого примитивного типа. Это важно учитывать при построении запросов с условиями отбора.

• 📂 Для справочников данные хранятся в регистре, привязанном к конкретному справочнику.
• 📄 Для документов структура аналогична, но может включать дополнительные измерения по версии или состоянию проведения.
• 🔗 Ссылки на объекты хранятся в измерении "Ссылка", что позволяет быстро соединять таблицы в запросах.
• ⚙️ Тип значения определяется в измерении "ВидДополнительногоРеквизита".

Особенности работы с планами счетов и отчетами

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

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

При работе с отчетами и обработками Это частая причина, почему пользовательские поля "не видны" в отчетах СКД (Система Компоновки Данных).

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

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

Объект 1С	Логическое имя регистра	Пример имени таблицы SQL	Тип хранения
Справочник "Контрагенты"	ДополнительныеРеквизитыКонтрагенты	_InfoRgAdditionalAttributesContractors	Регистр сведений
Документ "Реализация"	ДополнительныеРеквизитыРеализация	_InfoRgAdditionalAttributesSale	Регистр сведений
План счетов "Хозрасчетный"	ДополнительныеРеквизитыПланСчетов	_InfoRgAdditionalAttributesChartOfAccounts	Регистр сведений
Объекты без специфики	ДополнительныеРеквизитыОбъектов	_InfoRgAdditionalAttributesObjects	Универсальный регистр

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

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

Влияние характеристик на хранение данных

Отдельного упоминания заслуживает взаимосвязь дополнительных реквизитов и характеристик номенклатуры. Если дополнительный реквизит определен для вида номенклатуры, а номенклатура использует характеристики, то данные могут храниться с учетом измерения "Характеристика".

Это создает многомерную структуру данных. Один и тот же артикул товара с разными характеристиками (например, "Размер: L" и "Размер: XL") может иметь совершенно разные значения в дополнительных реквизитах. Механизм 1С автоматически учитывает это при записи и чтении.

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

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

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

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

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

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

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

Частые ошибки и способы их решения

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

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

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

Где найти имя физического регистра в конфигураторе?

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

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

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

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

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

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

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