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

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

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

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

Архитектура хранения в файловом варианте базы данных

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

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

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

⚠️ Внимание: Никогда не пытайтесь открывать файл .1CD в текстовых редакторах или hex-редакторах с целью изменения конкретных ячеек. Это гарантированно приведет к ошибке целостности базы данных при следующей попытке входа.

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

Таблицы в клиент-серверном варианте (SQL Server, PostgreSQL)

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

Имена этих таблиц формируются по определенному алгоритму. Обычно они начинаются с префикса _InfoRg (для регистров сведений, которыми по сути являются допреки) или _AccRg, за которым следует уникальный идентификатор метаданных. Например, таблица может называться _InfoRg12345. Чтобы понять, какой таблице соответствует какой реквизит, необходимо обратиться к системным таблицам конфигурации.

Рассмотрим типичную структуру такой таблицы в SQL Server. Она обязательно содержит поля для ссылки на основной объект (например, _RecordRef), номер строки (если реквизит табличный), а также поля для хранения значений разных типов.

Имя поля в SQL	Тип данных	Описание назначения
_RecordRef	Binary(20) / UUID	Ссылка на объект (справочник, документ), к которому относится реквизит
_LineNo	Int	Порядковый номер строки (для табличных частей)
_ValueTYPE	SmallInt	Тип хранимого значения (строка, число, дата, ссылка)
_ValueRRef	Binary(20)	Хранение значений типа «Ссылка» (уникальный идентификатор)
_ValueRTRef	Binary(4)	Тип ссылки (идентификатор таблицы метаданных)

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

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

Справочник «Дополнительные сведения» как альтернатива

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

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

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

Структура хранения в этом случае более предсказуема: это обычная таблица справочника со стандартными полями ссылок и табличной частью для значений. Найти её в SQL можно по имени, содержащему слово AdditionalInformation или по синониму, заданному в конфигураторе.

Поиск значений через Консоль запросов и СКД

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

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

Рассмотрим пример построения запроса для получения значения дополнительного реквизита. Предположим, у нас есть справочник «Номенклатура» и мы добавили туда реквизит «АртикулПроизводителя».

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

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

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

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

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

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

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

• 🚀 Индексы по ссылкам: Обязательно проверяйте наличие индекса по полю ссылки на объект (_RecordRef). Без него поиск всех допреков для конкретного документа будет выполняться полным сканированием таблицы.
• 📉 Влияние на обновление: Каждый новый дополнительный реквизит увеличивает время проведения документов. При массовом обновлении базы это может увеличить общее время процесса на 10-15%.
• 🗄️ Фрагментация: В SQL Server таблицы с дополнительными реквизитами подвержены высокой фрагментации. Регулярная перестройка индексов (REORGANIZE/REBUILD) обязательна для поддержания скорости.

Как проверить фрагментацию индексов в SQL Server?

Выполните запрос к системному представлению sys.dm_db_index_physical_stats. Если уровень фрагментации превышает 30%, рекомендуется выполнить команду ALTER INDEX ... REBUILD.

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

Миграция и выгрузка данных в другие системы

При интеграции 1С с другими системами (сайты, CRM, ERP) часто возникает задача выгрузить значения дополнительных реквизитов. Стандартные механизмы обмена данными (КСД, JSON, XML) поддерживают выгрузку этих полей, но требуют правильной настройки правил регистрации.

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

При прямой выгрузке через ODBC или JDBC важно правильно интерпретировать типы данных. Например, булевы значения в 1С могут храниться в SQL как числа 0 и 1, а даты — с учетом часового пояса сервера.

Особое внимание следует уделить полям типа «Хранилище значения». При выгрузке в текстовые форматы (CSV) данные из таких полей будут потеряны или преобразованы в нечитаемый бинарный вид. Для таких случаев требуется специальная обработка в коде выгрузки.

⚠️ Внимание: Структура таблиц дополнительных реквизитов может измениться при обновлении платформы 1С. Не пишите жесткие SQL-запросы к системным таблицам в внешнем ПО. Используйте только официальный ODBC-драйвер 1С или веб-сервисы.

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

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

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

Где найти соответствие между именем таблицы в SQL и именем реквизита в 1С?

Соответствие хранится в системных таблицах конфигурации. В SQL Server это таблица _Params или представления каталога 1С. Также можно воспользоваться обработкой «Администрирование» -> «Техническая поддержка» -> «Технологический журнал», включив логирование SQL-запросов, и посмотреть, к какой таблице обращается система при чтении конкретного реквизита.

Влияют ли дополнительные реквизиты на размер файла базы данных?

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

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

Самый быстрый способ — использовать запрос в консоли с отбором по этому реквизиту (Условие: «Не Пустая Ссылка» или конкретное значение). Если реквизитов много и поиск идет часто, целесообразно создать отдельный регистр сведений, который будет агрегировать эти данные для быстрого поиска.

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

Стандартными средствами конфигурирования — нет. Механизм дополнительных реквизитов не поддерживает наложение уникальных индексов на значения. Для обеспечения уникальности необходимо писать код в модуле объекта (событие «ПередЗаписью»), который будет выполнять запрос на проверку существования такого значения в базе.