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

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

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

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

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

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

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

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

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

Физическая таблица хранения значений

Основным местом, где физически располагаются значения дополнительных реквизитов в современных версиях платформы, является служебная таблица базы данных. В терминах СУБД (MS SQL, PostgreSQL) эта таблица обычно имеет имя вида _AddRValues или _AddRValuesR для регистрационных данных. Именно здесь происходит консолидация всех разнородных данных.

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

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

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

Поле в БД	Описание	Тип данных
_Fld3600RRef	Ссылка на объект владельца	UniqueIdentifier
_Fld3600RLineID	Идентификатор строки табличной части	UniqueIdentifier
_Fld3600RPropID	Идентификатор свойства (доп. реквизита)	UniqueIdentifier
_Fld3600RValue	Значение реквизита (универсальное)	SQL_Variant / Bytea

Особенности хранения табличных частей

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

Для реализации этого в таблице значений используется специальное поле — идентификатор строки (LineID). Каждая строка табличной части при записи получает уникальный UUID, который сохраняется в основной таблице табличной части и дублируется в записи таблицы дополнительных реквизитов. Это обеспечивает жесткую связь между строкой и ее расширенными атрибутами.

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

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

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

Технические детали UUID строк

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

Типизация данных и ограничения

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

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

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

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

Очистка и обслуживание таблицы значений

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

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

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

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

Использование дополнительных реквизитов накладывает определенный отпечаток на производительность системы. Каждый дополнительный реквизит, по которому ведется поиск или сортировка, должен быть проиндексирован. Без индекса сервер 1С вынужден выполнять полное сканирование таблицы значений, что при миллионах записей приводит к существенным задержкам.

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

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

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

⚠️ Внимание: Изменение свойств дополнительного реквизита (например, включение индексации) в работающей базе требует перестроения индексов. Эта операция может заблокировать работу пользователей на длительное время. Планируйте такие изменения на нерабочее время.

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

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

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

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

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

Что произойдет, если удалить запись из таблицы _AddRValues напрямую?

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

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

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

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

Идентификатор свойства можно найти в таблице метаданных конфигурации или через запрос к системным таблицам 1С (например, InformationRegister.AdditionalFieldsSettings). В имени поля таблицы значений он обычно зашифрован как часть имени колонки (например, _Fld3600...).

Где искать ID свойства

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