Стоит ли использовать дополнительные реквизиты БСП или лучше добавлять реквизиты через конфигуратор и расширения?

← На главную

Приветствуем вас, уважаемые коллеги! Сегодня мы детально разберем крайне важную архитектурную дилемму, с которой рано или поздно сталкивается любой разработчик на платформе 1С:Предприятие 8. Что выбрать: использовать типовой механизм дополнительных реквизитов и сведений, предоставляемый Библиотекой Стандартных Подсистем (БСП), или же надежнее и проще добавлять поля непосредственно в конфигураторе (либо через расширения)?

На первый взгляд кажется, что дополнительные реквизиты БСП — это идеальное решение, ведь они позволяют добавлять новые свойства объектам прямо в режиме 1С:Предприятие без изменения метаданных. Однако при реальной разработке и написании запросов программисты сталкиваются с лавинообразным ростом сложности кода и падением производительности. Давайте вместе проанализируем эту ситуацию, разберем все «за» и «против», рассмотрим влияние различных подходов на СУБД и найдем оптимальные пути решения.

В чем суть проблемы: архитектура дополнительных реквизитов БСП

Для начала выясним причину, почему автор темы на форуме жалуется на усложнение запросов. Механизм дополнительных реквизитов БСП построен на классической схеме Entity-Attribute-Value (Сущность-Атрибут-Значение). Физически в СУБД это означает следующее: значения всех дополнительных реквизитов конкретного объекта (например, справочника Номенклатура) хранятся не в отдельных колонках основной таблицы, а во вложенной табличной части ДополнительныеРеквизиты.

Представим, что нам нужно выбрать из базы данных номенклатуру и вывести три ее дополнительных реквизита: «Цвет» (булево), «Размер» (строка) и «Сезонность» (справочник). Если бы это были обычные реквизиты конфигурации, наш запрос выглядел бы предельно просто:


ВЫБРАТЬ
    Номенклатура.Ссылка КАК Товар,
    Номенклатура.Цвет КАК Цвет,
    Номенклатура.Размер КАК Размер,
    Номенклатура.Сезонность КАК Сезонность
ИЗ
    Справочник.Номенклатура КАК Номенклатура

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


ВЫБРАТЬ
    Номенклатура.Ссылка КАК Товар,
    ДопРеквизитЦвет.Значение КАК Цвет,
    ДопРеквизитРазмер.Значение КАК Размер,
    ДопРеквизитСезонность.Значение КАК Сезонность
ИЗ
    Справочник.Номенклатура КАК Номенклатура
    
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизитЦвет
        ПО ДопРеквизитЦвет.Ссылка = Номенклатура.Ссылка
        И ДопРеквизитЦвет.Свойство = &СвойствоЦвет
        
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизитРазмер
        ПО ДопРеквизитРазмер.Ссылка = Номенклатура.Ссылка
        И ДопРеквизитРазмер.Свойство = &СвойствоРазмер
        
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизитСезонность
        ПО ДопРеквизитСезонность.Ссылка = Номенклатура.Ссылка
        И ДопРеквизитСезонность.Свойство = &СвойствоСезонность

Как справедливо замечают участники обсуждения, если в запросе соединяются 7-10 основных таблиц базы данных, и к ним требуется пристыковать еще 5 левых соединений ради получения дополнительных реквизитов — это превращается в настоящий кошмар разработчика. Теряется читабельность кода, увеличивается вероятность ошибок, а скорость разработки падает в разы.

Влияние на производительность СУБД и проблему индексации

Помимо неудобства написания кода, существует гораздо более опасная проблема — производительность СУБД на больших массивах данных. Проанализируем, как ведут себя СУБД (MS SQL Server или PostgreSQL) при выполнении подобных запросов.

Проблема индексации: Если мы добавляем реквизит через конфигуратор (или расширение), платформа создает физическую колонку в таблице СУБД. Мы можем легко установить у этого реквизита свойство «Индексировать» (или «Индексировать с дополнительным упорядочиванием»). СУБД построит индекс, и поиск или фильтрация по этому полю на миллионной базе займет доли миллисекунды. В случае с БСП все дополнительные реквизиты хранятся в куче одной табличной части. Создать индивидуальный индекс для конкретного свойства в табличной части невозможно. При поиске по значению дополнительного реквизита СУБД будет вынуждена выполнять полное сканирование таблицы (Table Scan), что приведет к колоссальным блокировкам и зависаниям системы.
Сложные планы запросов: Когда оптимизатор запросов СУБД видит запрос с пятью и более левыми соединениями к одной и той же табличной части по неиндексированным полям, он часто ошибается в выборе оптимального плана выполнения. Это приводит к неоптимальному использованию оперативной памяти сервера и процессора.

Альтернатива: Использование расширений конфигурации

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

Рассмотрим преимущества добавления реквизитов через расширение:

Сохранение типовой конфигурации на поддержке: Основная конфигурация остается абсолютно чистой. Это решает проблему «геморройных обновлений», о которой так беспокоился автор темы.
Физические колонки в СУБД: Реквизиты, добавленные в объекты через расширение, физически создаются в СУБД как полноценные поля таблиц. К ним можно обращаться напрямую через точку (Номенклатура.МойРеквизит) в любых запросах.
Возможность индексации: Вы можете полноценно индексировать добавленные в расширении реквизиты, обеспечивая максимальную скорость поиска и отборов.

Платформенный механизм «Характеристики» как спасение для отчетов

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

На уровне платформы 1С и Системы компоновки данных (СКД) реализован мощный механизм — «Характеристики». Разберем по шагам, как его задействовать:

В схеме компоновки данных (или в настройках динамического списка) перейдем на вкладку «Характеристики».
Опишем связь нашего объекта (например, справочника Номенклатура) с планом видов характеристик дополнительных реквизитов и таблицей их значений.
После этой настройки платформа начнет воспринимать эти свойства как виртуальные реквизиты объекта. При конструировании отчетов или настройке динамического списка пользователи и разработчик смогут перетаскивать эти поля напрямую через точку: Номенклатура.[ИмяДопРеквизита]. Платформа сама «под капотом» сгенерирует оптимальный SQL-запрос с необходимыми левыми соединениями.

Разница между дополнительными реквизитами и дополнительными сведениями

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

Дополнительные реквизиты: Хранятся непосредственно внутри самого объекта (в его табличной части). Любое изменение дополнительного реквизита приводит к перезаписи самого объекта, увеличению номера его версии в истории изменений. Такое изменение блокируется установленной в системе датой запрета редактирования.
Дополнительные сведения: Хранятся отдельно от объекта во внешнем независимом регистре сведений ДополнительныеСведения. Их можно изменять даже у закрытых документов прошлых периодов без перезаписи самого документа, не опасаясь нарушения последовательностей или блокировок со стороны даты запрета.

Использование готового программного интерфейса (API) БСП

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

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


ЗначениеСвойства = УправлениеСвойствами.ЗначениеСвойства(СсылкаНаНоменклатуру, "МойДополнительныйРеквизит");

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


ТаблицаСвойств = УправлениеСвойствами.ЗначенияСвойств(СсылкаНаНоменклатуру);
// На выходе получаем таблицу с колонками "Свойство" и "Значение"

Использование этого готового API значительно повышает читаемость кода, сокращает количество строк и перекладывает задачу оптимизации выборки на плечи проверенных временем механизмов БСП.

Временные таблицы как способ упрощения сложных запросов

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

Вместо того чтобы делать гигантское левое соединение 10 таблиц в одном пакете, разбейте задачу на шаги:

Сначала выберите во временную таблицу только нужные ссылки (например, отфильтрованную номенклатуру).
Затем во вторую временную таблицу выберите значения необходимых дополнительных реквизитов только для отобранных ссылок.
В финальном запросе соедините эти временные таблицы. Такой подход гарантирует, что оптимизатор СУБД построит максимально эффективный план выполнения запроса.

Резюме: когда и что выбирать?

Подведем итог и составим краткое руководство для принятия архитектурных решений при проектировании систем на платформе 1С:

Используйте дополнительные реквизиты БСП, если:

Конфигурация находится на строгой поддержке поставщика, и внедрение расширений по каким-то причинам нежелательно или невозможно.
Новые свойства объектов должны создаваться обычными пользователями (администраторами системы) «на лету» без участия программиста и обновления конфигурации.
Эти свойства используются редко, в основном для вывода информации в специализированные отчеты через механизм характеристик СКД.

Добавляйте реквизиты через конфигуратор или расширения, если:

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