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

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

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

Архитектура хранения динамических свойств

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

Физически данные размещаются в таблицах, имена которых начинаются с префикса _AddR или _AddRS. Это сделано для того, чтобы отделить динамические данные от статической структуры объектов. Когда вы создаете новый дополнительный реквизит в конфигураторе, система не добавляет колонку в таблицу справочника"Номенклатура" или документа"Реализация". Вместо этого она регистрирует описание этого реквизита в словаре и выделяет место в универсальных таблицах значений.

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

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

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

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

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

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

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

Чтобы понять, какому именно свойству соответствует то или иное значение из таблицы _AddR, необходимо обратиться к словарю метаданных. Эта информация хранится в таблице _AddRDef (или _AddRDefinitions в некоторых версиях). Именно здесь содержится описание каждого дополнительного реквизита: его имя, тип данных, привязка к объекту и внутренний номер.

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

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

• 📂 Таблица _AddRDef содержит имена и типы всех созданных реквизитов.
• 🔗 Связь между значением и определением осуществляется через поле _Fld или аналогичный идентификатор порядка.
• 📝 В словаре также хранится информация о владельце реквизита (справочник, документ, план счетов).
• 🔄 При изменении конфигурации словарь обновляется, но старые значения в таблице _AddR сохраняются.

Специфика хранения в табличных частях

Ситуация усложняется, когда дополнительные реквизиты добавляются не к самому объекту, а к его табличной части. В этом случае система использует отдельный механизм хранения, часто обозначаемый префиксом _AddRS (где S означает String или Sub-table). Логика остается схожей: есть таблица значений и есть словарь, но ключи связи включают в себя идентификатор строки табличной части.

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

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

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

Поиск данных через консоль СУБД

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

SELECT 
T._Name AS PropertyName,
V._Value AS PropertyValue,
O._Description AS ObjectName
FROM _AddRDef T
JOIN _AddR V ON T._Order = V._Fld
JOIN _Reference12 O ON V._IDRRef = O._IDRRef
WHERE O._Description ='НужныйЭлемент'

В данном примере мы соединяем словарь определений, таблицу значений и таблицу самого справочника (в данном случае условно _Reference12). Поле _Fld в таблице значений ссылается на порядок реквизита в словаре. Это позволяет расшифровать, что именно хранится в ячейке значения. Обратите внимание, что типы данных в колонке _Value могут быть представлены в специфическом бинарном или текстовом формате 1С, требующем конвертации.

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

Особенности типов данных в SQL

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

Сравнение методов доступа к данным

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

Метод доступа	Инструмент	Сложность реализации	Риск повреждения данных
Встроенный язык 1С	Конфигуратор / Предприятие	Низкая	Минимальный
Прямой SQL запрос	SSMS / pgAdmin	Высокая	Средний (при чтении)
Внешние обработки	C# / Python / COM	Средняя	Низкий
СКД (Система Компоновки Данных)	Конструктор запросов	Средняя	Отсутствует

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

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

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

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

Также стоит упомянуть проблему производительности. Поскольку данные разбросаны по строкам, выборка большого количества дополнительных реквизитов для множества объектов может требовать значительных ресурсов сервера. Неоптимизированные запросы с множественными соединениями к таблице _AddR способны"положить" базу данных в часы пиковой нагрузки.

• ❌ Ошибка: Поиск колонки с именем реквизита в основной таблице справочника.
• ❌ Ошибка: Игнорирование необходимости соединения со словарем _AddRDef.
• ❌ Ошибка: Попытка обновить данные напрямую в SQL без понимания форматов хранения 1С.
• ✅ Решение: Использовать объект метаданных"ДополнительныеРеквизитыСведений" в коде 1С.

Можно ли удалить таблицу _AddR, если она занимает много места?

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

Почему в SQL я вижу непонятные числа вместо текста в поле значения?

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

Влияет ли количество доп. реквизитов на скорость работы 1С?

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

Где хранятся доп. реквизиты регистров сведений?

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

Как найти ID дополнительного реквизита для SQL запроса?

Выполните выборку из таблицы _AddRDef, отфильтровав результаты по полю _Name (имя реквизита). Полученное значение поля _Order или _ID и будет тем идентификатором, который используется в таблице значений _AddR в колонке ссылки на определение.