При доработке типовых или кастомных решений на платформе «1С:Предприятие 8.3» перед каждым разработчиком встает важный архитектурный вопрос: где создавать новые реквизиты? С одной стороны, расширения конфигурации манят возможностью оставить основную конфигурацию на полной поддержке («на замке»), что существенно упрощает последующие обновления. С другой стороны, хранение бизнес-данных в таблицах расширений сопряжено с серьезными технологическими рисками, угрозой потери информации и падением производительности СУБД. В рамках этой статьи мы детально проанализируем обе стороны этой медали, разберем практические кейсы, системные ограничения платформы и выработаем оптимальную стратегию (Best Practices) для безопасной и быстрой разработки.
Рассмотрим детально, как платформа 1С работает с данными расширений при различных административных манипуляциях. Это фундаментальный вопрос безопасности, который часто упускают из виду начинающие специалисты.
Выясним разницу между отключением расширения и его удалением:
Проанализируем ситуацию: в процессе обновления или технического обслуживания базы данных сторонний специалист может случайно удалить «мешающее» расширение, не зная, что в нем хранятся важные коммерческие данные. Именно поэтому хранение уникальной информации в реквизитах расширений считается крайне рискованным подходом.
Посмотрим, как добавление реквизитов через расширение влияет на физическую структуру таблиц СУБД (например, MS SQL Server или PostgreSQL) и стабильность работы системы.
При добавлении нового реквизита в основную конфигурацию платформа создает колонку в уже существующей таблице соответствующего объекта метаданных. Все запросы к этому объекту выполняются быстро и прямолинейно.
Если же мы добавляем реквизит в расширении, платформа вынуждена создавать в СУБД отдельную вспомогательную таблицу. При каждом обращении к объекту (например, при чтении документа или формировании отчета) система выполняет операцию LEFT JOIN (левое соединение) основной таблицы и таблицы расширения по уникальному идентификатору (Ссылка). Это приводит к следующим проблемам:
Разработчикам необходимо четко понимать технологические границы механизма расширений. Платформа накладывает жесткие запреты на создание определенных типов объектов в расширениях. В расширениях категорически запрещено:
ЛюбаяСсылка для добавленных реквизитов, так как он не будет автоматически включать в себя новые типы объектов, созданные в расширениях.Если ваша система работает по схеме РИБ (распределенная информационная база), использование расширений, меняющих структуру данных, превращается в постоянный источник головной боли для системных администраторов. При синхронизации метаданных между главным и периферийными узлами регулярно возникают блокирующие ошибки:
Данные принимаются от узла с другим набором расширений, меняющих структуру данных
Или аварийные завершения работы программы на подчиненных узлах в момент применения изменений конфигурации. Зачастую для восстановления обмена приходится отключать периферийный узел от РИБ, вручную выравнивать конфигурацию расширений и заново собирать начальный образ, что влечет за собой огромные трудозатраты.
Как же поступить, если бизнес-требования обязывают добавить новое поле на форму типового документа, но мы хотим избежать вышеописанных проблем? Рассмотрим два наиболее надежных и проверенных временем решения.
Если ваша конфигурация построена на базе БСП (Библиотека Стандартных Подсистем), например, «1С:ERP», «1С:Комплексная автоматизация», «1С:Управление торговлей» или «1С:Бухгалтерия», то самым безопасным решением будет использование типового функционала дополнительных свойств.
Разберем по шагам, как это работает:
ДополнительныеРеквизиты, которая изначально заложена в структуру конфигурации и оптимизирована для работы.Например, получение значения дополнительного реквизита программным путем выглядит так:
ЗначениеСвойства = УправлениеСвойствами.ЗначениеСвойства(СсылкаНаОбъект, "ИмяНашегоДополнительногоРеквизита");
Если ЗначениеСвойства = Истина Тогда
// Выполняем необходимую логику
КонецЕсли;
Этот подход гарантирует 100% сохранность данных при любых обновлениях и манипуляциях с расширениями, так как физически данные лежат в стандартных таблицах БСП.
Если типовой механизм БСП по каким-то причинам не подходит (например, требуется связать реквизит сложными индексами или использовать его в высокопроизводительных запросах), используйте гибридную схему:
Проанализируем пример программного вывода созданного в основной конфигурации реквизита на форму через расширение:
&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Программное добавление элемента формы для реквизита основной конфигурации
НовыйЭлемент = Элементы.Добавить("НашНовыйРеквизит", Тип("ПолеФормы"), Элементы.ГруппаРеквизитов);
НовыйЭлемент.ПутьКДанным = "Объект.НашНовыйРеквизит";
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
КонецПроцедуры
При таком подходе при обновлении типовой конфигурации вам не придется вручную переносить изменения форм, так как они находятся в расширении. В то же время ваши бизнес-данные надежно защищены внутри основной конфигурации.
Подводя итоги, сформируем краткое правило для разработчика 1С: