Стоит ли использовать общие реквизиты в 1С для фиксации авторства и системных данных?

При проектировании структуры новой конфигурации или доработке существующей часто возникает соблазн использовать объект ОбщиеРеквизиты. Кажется логичным один раз создать поля Автор, ДатаСоздания или ИдентификаторBitrix и просто «проставить галочки» у нужных документов и справочников. Однако этот инструмент имеет глубокие архитектурные последствия. Рассмотрим подробнее, как работают общие реквизиты, какие преимущества они дают и с какими скрытыми проблемами может столкнуться разработчик.

Назначение общих реквизитов и их роль в модели сервиса

Первоочередная задача, для которой фирма 1С внедряла общие реквизиты в платформу 8.2, — это поддержка работы в модели сервиса (SaaS). Если мы проанализируем типовые решения, такие как БП 3.0 или УТ 11, то увидим, что общие реквизиты используются там практически исключительно как разделители данных. Разберем, что это дает:

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

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

Техническое устройство на уровне СУБД

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

Важный нюанс: Любое изменение свойств общего реквизита (изменение типа данных, изменение состава объектов, в которых он используется) инициирует реструктуризацию всех таблиц, входящих в этот реквизит. Если вы добавили общий реквизит Автор в 50 видов документов и решили изменить его тип или добавить 51-й документ, платформа будет пересоздавать таблицы всех 50 документов. В высоконагруженных или больших базах это может привести к многочасовому простою системы.

Проблемы при работе с метаданными и кодом

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

// Обычный способ не увидит общий реквизит
Если Метаданные.Документы.РеализацияТоваровУслуг.Реквизиты.Найти("Автор") = Неопределено Тогда
    Сообщить("Реквизит не найден!");
КонецЕсли;

Чтобы программно определить, есть ли у объекта общий реквизит, нам придется проанализировать всю коллекцию Метаданные.ОбщиеРеквизиты и проверить свойство Состав каждого из них. Это усложняет написание универсальных процедур, например, в Библиотеке стандартных подсистем (БСП). Именно поэтому 1С не переводит стандартные поля Ответственный или Комментарий в разряд общих — это потребовало бы глобальной переработки кода сотен подсистем.

Оптимизация прав доступа (RLS)

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

Если вам нужно ограничить доступ ко всем документам системы по одному и тому же полю (например, ОбластьДанных или ПодразделениеДоступа), использование общего реквизита позволяет написать одно компактное правило доступа. Платформа обрабатывает такие запросы быстрее, чем если бы в каждом документе было свое уникальное поле. Это значительно упрощает поддержку кода безопасности и снижает нагрузку на SQL-сервер при построении планов запросов.

Почему в типовых конфигурациях нет общих реквизитов для «Комментария»?

Проанализируем ситуацию, описанную участниками обсуждения: почему 1С не использует этот механизм для поля Комментарий?

• Историческое наследие: Типовые конфигурации развиваются десятилетиями. Массовый перенос данных из локальных реквизитов в общие — это огромный риск потери данных и колоссальные затраты на миграцию у миллионов пользователей.
• Типы данных: Поле Комментарий часто имеет неограниченную длину. Использование полей неограниченной длины в общих реквизитах, которые могут быть проиндексированы или использованы как разделители, крайне нежелательно.
• Версионирование: Современные механизмы БСП (версионирование объектов) отлично справляются с отслеживанием того, кто и когда изменил документ, без создания лишних полей в структуре метаданных.

Практические рекомендации

На основе опыта ведущих разработчиков, сформулируем правила использования этого объекта:

1. Для простых конфигураций «с нуля»: Если вы пишете небольшую самописную систему, использовать общие реквизиты для полей Автор или ДатаРедактирования можно. Это ускорит разработку и обеспечит единообразие.
2. Для крупных систем: Избегайте общих реквизитов для «бытовых» нужд. Используйте их только для реализации механизмов разделения данных или специфической оптимизации RLS.
3. Индексация: Если вы планируете искать данные или фильтровать списки по общему реквизиту, обязательно проверьте свойство Индексировать. Без индекса поиск по общему журналу документов будет крайне медленным.
4. Программный доступ: При написании кода для проверки наличия реквизита используйте методы БСП или создайте свою функцию-обертку, которая учитывает коллекцию Метаданные.ОбщиеРеквизиты.

Посмотрим на пример правильной проверки наличия реквизита (с учетом общих):

Функция ЕстьРеквизитОбъекта(ИмяРеквизита, МетаданныеОбъекта) Экспорт
    // Проверяем обычные реквизиты
    Если МетаданныеОбъекта.Реквизиты.Найти(ИмяРеквизита) <> Неопределено Тогда
        Возврат Истина;
    КонецЕсли;
    
    // Проверяем общие реквизиты
    Для Каждого ОбщийРеквизит Из Метаданные.ОбщиеРеквизиты Цикл
        Если ОбщийРеквизит.Имя = ИмяРеквизита Тогда
            ЭлементСостава = ОбщийРеквизит.Состав.Найти(МетаданныеОбъекта);
            Если ЭлементСостава <> Неопределено 
                 И ЭлементСостава.Использование = Метаданные.ВариантИспользованияОбщегоРеквизита.Использовать Тогда
                Возврат Истина;
            КонецЕсли;
        КонецЕсли;
    КонецЦикла;
    
    Возврат Ложь;
КонецФункции

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