Почему контактная информация в современных конфигурациях 1С хранится в табличных частях, а не в общем регистре?

В процессе развития типовых конфигураций (УТ 11, ERP 2, КА 2), построенных на базе Библиотеки стандартных подсистем (БСП), многие разработчики заметили существенное изменение: контактная информация (адреса, телефоны, email) переехала из общего централизованного регистра сведений в табличные части каждого конкретного справочника. На первый взгляд это может показаться шагом назад к денормализации данных, однако за этим решением стоят серьезные архитектурные требования. Рассмотрим подробно, почему разработчики 1С приняли такое решение и какие преимущества это дает.

1. Оптимизация прав доступа и производительность RLS

Одной из главных причин переноса данных является механизм RLS (Record Level Security) — ограничение доступа на уровне записей. Проанализируем ситуацию, когда контактная информация хранится в едином регистре сведений:

1. При использовании общего регистра система вынуждена проверять права доступа к каждой записи, ориентируясь на владельца (контрагента, физическое лицо и т.д.).
2. Если в базе сотни тысяч контрагентов и миллионы записей контактной информации, запросы с наложенными правилами RLS начинают катастрофически тормозить, так как SQL-серверу приходится выполнять сложные соединения для проверки прав на каждую строку.
3. Перенос данных в табличную часть (ТЧ) решает эту проблему радикально: контактная информация становится неотъемлемой частью самого объекта. Если у пользователя есть права на чтение справочника Контрагенты, он автоматически получает доступ к его табличной части. Системе больше не нужно проверять права на отдельную таблицу регистра, что существенно повышает общую производительность системы в крупных базах данных.

2. Целостность данных и упрощение обмена (XML/РИБ)

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

Рассмотрим преимущества хранения в ТЧ для обмена:

• Объектная целостность: Контактная информация выгружается вместе с основным объектом как его часть. Больше нет риска «потерять» адрес при переносе контрагента.
• Транзакционность: Запись объекта и его контактных данных происходит в рамках одной транзакции. Невозможна ситуация, когда контрагент создался, а запись в регистр сведений не прошла из-за ошибки.

3. Поддержка версионирования объектов

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

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

4. Хранение сложных структур (XML и ФИАС)

Современные требования к хранению адресов предполагают наличие детальной информации: индекс, регион, город, улица, номер дома по ФИАС и т.д. В табличных частях БСП используется поле ЗначенияПолей, где вся структура адреса хранится в формате XML.

Посмотрим на пример того, как это упрощает структуру БД:

• Вместо создания 20–30 колонок в таблице для каждого элемента адреса, используется одно текстовое поле неограниченной длины.
• Это позволяет легко расширять состав хранимых данных без изменения структуры метаданных (добавление новых полей в XML не требует реструктуризации таблиц SQL).

5. Гибкость и множественность значений

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

6. Работа с запросами к контактной информации

Многие разработчики жалуются, что теперь запросы стали сложнее, так как требуется делать ЛЕВОЕ СОЕДИНЕНИЕ с табличной частью вместо обращения к одной таблице регистра. Однако, с точки зрения SQL, обращение к таблице _ReferenceXXX_VT_YYY (табличная часть) часто быстрее, чем поиск по огромному общему регистру всех видов информации.

Посмотрим на типичный пример запроса для получения телефона и email контрагента из табличной части:

ВЫБРАТЬ
    Партнеры.Ссылка КАК Партнер,
    ЕСТЬNULL(КИ_Телефон.Представление, "") КАК Телефон,
    ЕСТЬNULL(КИ_Email.Представление, "") КАК ЭлектроннаяПочта
ИЗ
    Справочник.Партнеры КАК Партнеры
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры.КонтактнаяИнформация КАК КИ_Телефон
        ПО Партнеры.Ссылка = КИ_Телефон.Ссылка
        И КИ_Телефон.Вид = &ВидКИ_Телефон
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры.КонтактнаяИнформация КАК КИ_Email
        ПО Партнеры.Ссылка = КИ_Email.Ссылка
        И КИ_Email.Вид = &ВидКИ_Email

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

7. Итоги и рекомендации

Подведем итоги нашего анализа. Перенос контактной информации в табличные части — это осознанное решение фирмы «1С» для повышения масштабируемости систем уровня Enterprise (ERP).

Основные выгоды:

1. Скорость: Отсутствие тяжелых проверок RLS на общей таблице.
2. Надежность: Данные всегда перемещаются вместе с объектом-владельцем.
3. Функциональность: Легкая интеграция с версионированием и ФИАС.

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