При разработке на платформе 1С:Предприятие 8.3 часто возникает дилемма: нужно добавить новые объекты (справочники, регистры сведений), но конфигурация находится на поддержке. С одной стороны, хочется оставить основную конфигурацию «на замке» для упрощения будущих обновлений, с другой — использование расширений для хранения данных несет в себе определенные риски. Разберем эту ситуацию подробно, проанализировав технические нюансы и возможные последствия каждого решения.
Проанализируем, как платформа работает с данными расширений на уровне системы управления базами данных (СУБД). В отличие от объектов основной конфигурации, таблицы объектов расширения создаются в базе данных под особыми внутренними именами с уникальными префиксами. Это критически важный момент, который мы должны учитывать при администрировании системы.
Риск безвозвратной потери данных. Если вы удалите расширение через конфигуратор или консоль администрирования кластера, платформа физически удалит соответствующие таблицы из SQL-базы. В основной конфигурации удаление объекта требует осознанного принятия изменений (нажатия кнопки «Принять»), тогда как в расширении это происходит гораздо быстрее и «незаметнее». Мы должны помнить: нет расширения — нет данных в его таблицах. Поэтому при использовании такого подхода наличие актуальных бэкапов становится жизненно важным условием.
Рассмотрим вопрос производительности, который часто вызывает споры среди разработчиков. Выясним, как добавление объектов влияет на скорость работы:
Разберем технические барьеры, с которыми мы можем столкнуться. Возможность добавления собственных объектов данных в расширения зависит от режима совместимости основной конфигурации. Для полноценной работы требуется режим не ниже 8.3.11 для базовых сущностей, а для более сложных механизмов — еще выше. Если ваша конфигурация работает на старом режиме совместимости, добавление объектов через расширение может быть технически невозможным без изменения этого режима. А изменение режима совместимости автоматически снимает конфигурацию с полной поддержки, что сводит на нет изначальную цель.
Также важно учитывать назначение самого расширения. Посмотрим на классификацию типов:
Проанализируем ситуацию с обменом данными, особенно если в вашей системе используется распределенная информационная база (РИБ). По умолчанию данные объектов расширения не участвуют в стандартном обмене. Для их миграции между узлами нам потребуются дополнительные программные доработки или использование специфических платформенных механизмов синхронизации, которые могут работать нестабильно в сложных топологиях. Если новые данные должны «путешествовать» по всей сети филиалов, использование расширения значительно усложнит жизнь разработчику.
Также стоит упомянуть сложности в отчетах и запросах. Мы не сможем использовать объект расширения в типовом отчете на СКД, который находится в основной конфигурации, без внесения этого отчета в само расширение. Кроме того, существуют нюансы с индексами при написании сложных запросов, объединяющих таблицы разных уровней.
Выясним, как обстоят дела с правами доступа. Для новых объектов в расширении необходимо создавать свои роли внутри этого же расширения. Однако типовые механизмы Библиотеки стандартных подсистем (БСП), такие как автоматическое управление профилями групп доступа, могут некорректно работать с объектами расширений. Часто права приходится настраивать и обновлять вручную после каждого изменения состава объектов.
Вопрос ссылочной целостности: Если со временем вы решите перенести объект из расширения в основную конфигурацию, «простой» перенос невозможен. С точки зрения платформы это будут два разных объекта с разными уникальными идентификаторами (UUID). Нам придется писать специальную обработку для переноса данных.
Рассмотрим пример логики, которую придется реализовать при таком переезде:
// Примерный алгоритм переноса данных (псевдокод)
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ * ИЗ Справочник.НовыйОбъектРасширения";
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
НовыйЭлемент = Справочники.НовыйОбъектОсновнойКонфы.СоздатьЭлемент();
ЗаполнитьЗначенияСвойств(НовыйЭлемент, Выборка);
НовыйЭлемент.Записать();
КонецЦикла;
Подведем итог нашему анализу. Выбор между расширением и основной конфигурацией должен зависеть от масштаба задачи.
Когда использовать расширение:
Когда использовать основную конфигурацию:
Помните, что добавление новых объектов в основную конфигурацию (даже если она на поддержке) практически не усложняет процесс обновления. Новые объекты не конфликтуют с типовыми при автоматическом обновлении, зато вы получаете стабильность и предсказуемость поведения системы.