При разработке и сопровождении систем на платформе «1С:Предприятие 8.3» часто возникает необходимость кастомизации типовых конфигураций. Добавление новых реквизитов в существующие справочники или документы через расширения конфигурации стало стандартом де-факто. Однако у многих разработчиков и администраторов баз данных возникает закономерный вопрос: что произойдет с данными, если расширение «отвалится», будет временно отключено или случайно удалено?
В этой статье мы подробно разберем, как устроена работа с данными расширений на уровне систем управления базами данных (СУБД), какие защитные механизмы встроены в платформу 1С и с какими скрытыми рисками можно столкнуться при использовании этого механизма.
Для того чтобы оценить безопасность добавления реквизитов, проанализируем, как платформа «1С» взаимодействует с СУБД (будь то Microsoft SQL Server, PostgreSQL, IBM DB2 или Oracle). Когда мы добавляем новый реквизит к существующему объекту (например, справочнику Контрагенты) через расширение, платформа не просто добавляет новую колонку в существующую таблицу СУБД. Происходит сложный процесс реструктуризации:
_Reference45, то для расширения создается таблица _Reference45X._Reference45X. Основная (старая) таблица при этом остается незадействованной и замораживается.Выясним, что происходит, когда расширение временно отключается (например, снят флаг «Активно» в списке расширений). В этот момент платформа «1С» просто перенаправляет запросы обратно к исходной таблице без суффикса «X». Сама расширенная таблица с суффиксом «X» при этом не удаляется из базы данных. Данные вашего реквизита продолжают физически находиться в СУБД, просто платформа их временно «не видит» и не использует.
Рассмотрим подробнее два сценария поведения системы, которые принципиально отличаются с точки зрения сохранности информации.
В этом случае потери данных не происходит. Все накопленные в реквизитах расширения данные остаются в таблице СУБД с суффиксом «X». Однако здесь кроется серьезная логическая ловушка для бизнес-пользователей. Пока работа расширения не возобновлена, никто не сможет записывать данные в расширенный объект метаданных.
Если пользователь или фоновое задание попытается перезаписать элемент справочника или документ, платформа выдаст ошибку, так как структура активной конфигурации в данный момент не соответствует структуре данных, хранящейся в «замороженной» таблице расширения. Запись заблокируется до тех пор, пока расширение снова не перейдет в статус «Активно».
Если вы удаляете расширение (через Конфигуратор или в режиме «1С:Предприятие»), то происходит физическое удаление расширенной таблицы из СУБД. В этот момент происходит необратимая потеря данных. Все значения, которые были записаны в добавленные реквизиты, уничтожаются без возможности автоматического восстановления (вернуть их можно будет только из резервной копии базы данных).
Разработчики платформы предусмотрели защиту от случайного удаления данных. Посмотрим на основные защитные механизмы:
Проанализируем пример кода, который позволяет безопасно обойти список расширений и определить, какие из них содержат собственные данные в СУБД:
// Пример проверки расширений на изменение структуры данных
ВыборкаРасширений = РасширенияКонфигурации.Получить();
Для Каждого ТекущееРасширение Из ВыборкаРасширений Цикл
Если ТекущееРасширение.ИзменяетСтруктуруДанных() Тогда
ЗаписьЖурналаРегистрации(
"КонтрольРасширений",
УровеньЖурналаРегистрации.Предупреждение,
,
,
"Расширение '" + ТекущееРасширение.Имя + "' содержит данные в СУБД! Удаление приведет к потере данных."
);
КонецЕсли;
КонецЦикла;
Несмотря на то, что механизм расширения данных относительно безопасен при правильной эксплуатации, существует ряд скрытых архитектурных рисков, которые необходимо учитывать при проектировании систем.
Если в вашей компании настроена интеграция со сторонними сервисами (например, BI-системы, склады WMS, внешние сайты) через прямые запросы к СУБД, добавление реквизита через расширение гарантированно нарушит их работу. Внешние системы продолжат обращаться к стандартной таблице (например, _Reference45), которая перестанет обновляться, так как 1С начнет писать все новые данные в _Reference45X. Данные в интеграционных отчетах станут неактуальными.
На некоторых релизах платформы 1С:Предприятие (особенно ранних версиях ветки 8.3) наблюдались критические ошибки при выполнении стандартной процедуры «Тестирования и исправления». Если у справочника-владельца был добавлен реквизит через расширение, система при проверке логической целостности могла ошибочно посчитать ссылки на владельца у подчиненных справочников неверными и массово их очистить. Перед запуском ТиИ на базах с расширениями данных всегда делайте резервную копию и внимательно изучайте баг-трекер текущего релиза платформы.
Использование расширений с собственными реквизитами в распределенных базах накладывает жесткие требования к синхронизации. Версии расширений на главном и подчиненных узлах должны быть строго идентичны. Любое расхождение в структурах данных заблокирует обмен или приведет к непредсказуемым коллизиям в таблицах СУБД на узлах.
Реквизиты, добавляемые через расширение, имеют ряд ограничений. В них нельзя использовать типы данных, которые не могут входить в состав составных типов (например, ХранилищеЗначения или УникальныйИдентификатор).
Добавление реквизитов через расширения — это достаточно безопасный маневр при соблюдении базовой технической гигиены: