Где лучше хранить новые реквизиты: в расширении или в основной конфигурации 1С?

При доработке типовых конфигураций 1С перед каждым разработчиком встает дилемма: стоит ли добавлять новые реквизиты в основную конфигурацию, тем самым снимая объект с «замка», или воспользоваться механизмом расширений? Этот вопрос затрагивает не только удобство разработки, но и фундаментальные аспекты производительности, надежности хранения данных и корректности работы распределенных информационных баз (РИБ). В этой статье мы подробно разберем оба подхода, проанализируем технические нюансы и выясним, в каких ситуациях каждый из них будет наиболее оправданным.

Вариант 1: Добавление реквизитов в расширение конфигурации

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

Когда мы добавляем реквизит в расширение, платформа 1С не меняет структуру таблиц основной конфигурации в СУБД. Вместо этого создаются вспомогательные таблицы. Разберем техническую сторону: при каждом обращении к объекту система выполняет операцию LEFT JOIN между основной таблицей и таблицей расширения. На небольших базах это незаметно, но на высоконагруженных системах с миллионами записей это может привести к некоторому снижению производительности при чтении данных.

Основные преимущества расширений:

1. Чистота основной конфигурации: Конфигурация остается на поддержке, что позволяет обновлять ее в автоматическом или полуавтоматическом режиме.
2. Изоляция логики: Все ваши доработки собраны в одном контейнере, который можно легко отключить или перенести в другую аналогичную базу.
3. Использование аннотаций: Мы можем использовать мощные инструменты, такие как &ИзменениеИКонтроль, для модификации существующих процедур, не переписывая их полностью.

Критические риски и недостатки:

1. Риск потери данных: Это самый важный момент. Если администратор или программист случайно удалит расширение из списка, все данные, хранящиеся в реквизитах этого расширения, будут безвозвратно удалены из СУБД. В отличие от основной конфигурации, где удаление требует реструктуризации и принятия изменений, удаление расширения происходит мгновенно.
2. Проблемы с Конструктором запросов: Как отмечают многие разработчики, работать с реквизитами расширения в конструкторе запросов неудобно. Чтобы увидеть свой реквизит, необходимо сначала добавить сам объект (документ или справочник) в расширение.
3. Ограничения РИБ: Стандартный механизм распределенных баз плохо справляется с данными расширений. Если ваша база работает в режиме РИБ, передача данных по новым реквизитам потребует серьезного программирования и ручного изменения правил обмена.

Вариант 2: Добавление реквизитов в основную конфигурацию

Этот «классический» метод предполагает снятие объекта с поддержки и внесение изменений непосредственно в дерево метаданных основной конфигурации. Многие опытные разработчики до сих пор отдают предпочтение именно этому способу при работе с критически важными данными.

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

Преимущества основной конфигурации:

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

Недостатки:

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

Вариант 3: Использование дополнительных реквизитов БСП

Если конфигурация построена на базе Библиотеки Стандартных Подсистем (БСП), рассмотрим альтернативный путь — механизм «Дополнительные реквизиты и сведения». Это позволяет добавить поле в пользовательском режиме, не меняя структуру метаданных вообще.

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

// Пример программного управления свойствами доп. реквизитов
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
    // Управление видимостью через механизм БСП
    УправлениеСвойствами.ПриЧтенииНаСервере(ЭтотОбъект, ТекущийОбъект);
КонецПроцедуры

Однако помните, что данные дополнительных реквизитов хранятся в отдельной таблице значений (обычно это РегистрСведений.ДополнительныеЗначения или табличная часть ДополнительныеРеквизиты). Это делает написание запросов к ним более громоздким, так как требуется соединение по ссылке и владельцу свойства.

Сравнительный анализ: когда и что выбирать?

Чтобы принять окончательное решение, проанализируем задачи по следующим критериям:

1. Критичность данных:

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

2. Наличие РИБ:

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

3. Частота обновлений:

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

4. Производительность (Highload):

Для таблиц с миллионами записей (например, РегистрНакопления.ЗапасыИПотребности или Документ.ЗаказКлиента) лучше добавлять реквизиты в основную базу, чтобы избежать лишних JOIN в SQL-запросах.

Итоговые рекомендации

Выясним оптимальную стратегию «гибридного» подхода, которую применяют многие ведущие специалисты:

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

Пример использования аннотации в расширении для работы с реквизитом, добавленным в основную конфигурацию:

&ИзменениеИКонтроль("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    // Наш реквизит МойНовыйРеквизит физически находится в основной конфе
    // Но логику его заполнения мы вынесли в расширение
    Если ЭтотОбъект.МойНовыйРеквизит = Ложь Тогда
        // Выполняем действия
    КонецЕсли;
КонецПроцедуры

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