Вопрос об изменении способа хранения контактной информации (КИ) — адресов, телефонов, электронных почт — является одним из фундаментальных при изучении архитектуры современных типовых конфигураций на платформе 1С:Предприятие 8.3. В старых решениях (например, "Управление производственным предприятием" ред. 1.3 или "Управление торговлей" ред. 10.3) мы привыкли видеть общий регистр сведений КонтактнаяИнформация. Однако в актуальных редакциях (ERP 2, БП 3.0, УТ 11) данные "переехали" в табличные части самих справочников (Контрагенты, Организации, Физические лица). Разберем детально, какими техническими и архитектурными причинами обосновано это решение.
Одной из самых весомых причин является упрощение системы разграничения прав доступа на уровне записей (RLS). Рассмотрим ситуацию: когда контактная информация хранится в одном общем регистре сведений, для ограничения доступа к ней системе необходимо постоянно проверять права на "владельца" этой информации (например, на конкретного контрагента).
В случае с регистром сведений механизм RLS вынужден выполнять сложные вложенные запросы, чтобы определить, имеет ли пользователь право видеть запись в регистре, исходя из его прав на объект-владелец. Если в базе данных миллионы записей, это колоссально замедляет работу. При хранении данных в табличной части права наследуются автоматически: если у пользователя есть право на чтение справочника Контрагенты, он автоматически получает доступ к его табличной части КонтактнаяИнформация. Это избавляет сервер СУБД от лишних вычислений и накладных расходов на проверку прав в отдельной таблице.
Проанализируем структуру хранения данных на уровне базы данных SQL. В старой модели (регистр сведений) измерение Объект имело составной тип данных, включающий десятки различных справочников. Для SQL-сервера это означает, что поле типа "Ссылка" превращается в набор из нескольких колонок (тип и идентификатор), и при попытке получить данные система вынуждена выполнять многочисленные LEFT JOIN ко всем таблицам, входящим в составной тип, чтобы просто "понять", к какому объекту относится запись.
Перенос данных в табличную часть конкретного справочника позволяет нормализовать структуру на физическом уровне. Теперь данные КИ хранятся в подчиненной таблице этого конкретного справочника. Это существенно ускоряет выборку данных, так как платформа точно "знает", где лежат данные, и не выполняет избыточных соединений таблиц.
Рассмотрим процесс записи данных. При использовании регистра сведений запись элемента справочника и его контактной информации — это две технически разные операции. Даже если мы обернем их в одну транзакцию, это требует написания дополнительного кода и контроля.
Хранение в табличной части обеспечивает атомарность "из коробки". Когда мы вызываем метод Записать() у объекта, вся информация (реквизиты и табличные части) передается в СУБД и записывается единым пакетом. Это гарантирует:
ПередЗаписью и ПриЗаписи, так как вся контактная информация уже доступна в памяти объекта ЭтотОбъект без дополнительных запросов к базе данных.В современных конфигурациях, построенных на базе Библиотеки стандартных подсистем (БСП), активно используется механизм версионирования. Он позволяет отслеживать, кто и когда изменил данные объекта. Если контактная информация хранится в табличной части, подсистема версионирования автоматически "подхватывает" изменения адресов или телефонов вместе с изменениями самого контрагента.
Если бы данные хранились в отдельном регистре, разработчикам пришлось бы создавать сложную логику связки версий объекта и версий записей регистра, что усложнило бы поддержку системы и увеличило вероятность ошибок при обновлении конфигурации.
Выясним, как это влияет на интеграционные процессы. При выгрузке данных через XML или JSON (например, в распределенных информационных базах или при обмене между разными конфигурациями) объект со всеми его табличными частями представляет собой единую структуру. Нам не нужно заботиться о том, чтобы "довыгрузить" записи регистра сведений, связанные с этим объектом — они уже находятся внутри него. Это значительно упрощает механизмы синхронизации и гарантирует, что на приемной стороне объект появится сразу со всеми контактными данными.
Разберем, как реализована универсальность в БСП. Разработчики библиотеки пошли по пути создания унифицированных программных интерфейсов. Для внедрения функционала контактной информации в новый справочник программисту достаточно:
Это позволяет использовать общие формы и методы БСП, передавая в них просто ссылку на объект или сам объект целиком. Например, вызов программного интерфейса для получения представления адреса выглядит крайне лаконично, так как функции БСП "знают", что искать данные нужно именно в ТЧ объекта.
// Пример получения контактной информации через БСП
// Нам не нужно делать запрос к регистру, достаточно передать ссылку
ПараметрыАдреса = УправлениеКонтактнойИнформацией.СведенияОКонтактнойИнформации(ОбъектСсылка, "ЮридическийАдрес");
Представление = ПараметрыАдреса.Представление;
Несмотря на явные преимущества, у такого подхода есть и свои особенности, которые могут показаться минусами. Рассмотрим их:
Таким образом, переход от регистров сведений к табличным частям — это осознанный выбор в пользу производительности SQL, целостности данных и упрощения разработки в рамках экосистемы БСП. Это решение позволяет системе работать стабильнее при больших нагрузках и значительно упрощает сопровождение типовых конфигураций.