При разработке в среде 1С:Предприятие 8 многие программисты сталкиваются с ситуацией, когда добавление, казалось бы, изолированного объекта (например, нового вида документа) вызывает длительный процесс реструктуризации всей базы данных. На первый взгляд это кажется избыточным: мы не меняем структуру существующих таблиц, не редактируем старые реквизиты, а лишь создаем нечто новое. Однако архитектура СУБД и механизмы платформы 1С работают сложнее. Рассмотрим подробнее, какие именно факторы заставляют систему перестраивать таблицы и как это влияет на процесс обновления конфигурации.
Проанализируем одну из самых частых причин реструктуризации. В платформе 1С активно используются составные типы данных. Если в вашей конфигурации есть хотя бы один реквизит в любом справочнике, документе или регистре, имеющий тип ДокументСсылка (без указания конкретных видов) или ЛюбаяСсылка, это создает прямую зависимость.
Разберем ситуацию на уровне СУБД. Когда поле имеет составной тип, платформа хранит в соответствующих колонках таблиц SQL не только идентификатор объекта (UUID), но и код типа этого объекта. Как только мы добавляем в метаданные новый документ, общее количество возможных типов ссылок увеличивается. Платформа обязана обновить описания во всех таблицах, где потенциально может встретиться ссылка на новый объект. В некоторых случаях это приводит к физическому изменению структуры колонок или обновлению системных метаданных в таблицах СУБД, что и отображается пользователю как процесс реструктуризации.
Выясним, как на процесс влияют журналы документов. Журнал — это не просто виртуальное представление, а отдельная физическая таблица в базе данных (обычно с префиксом _DocumentJournal), которая агрегирует данные из разных типов документов для быстрого построения списков.
Если новый документ включается в состав какого-либо существующего журнала (даже если это происходит автоматически по умолчанию), платформа обязана модифицировать таблицу этого журнала. Поскольку журнал хранит ссылки на документы, добавление нового типа данных требует обновления индексов и, зачастую, перестроения всей таблицы журнала. Рассмотрим последовательность действий системы:
Проанализируем роль общих реквизитов. В современных конфигурациях (особенно типовых) часто используются общие реквизиты, такие как ОбластьДанныхОсновныеДанные (для работы в модели сервиса) или Комментарий. Если у общего реквизита установлено свойство «Использовать автоматически», то при создании любого нового объекта метаданных этот реквизит автоматически «приклеивается» к нему.
Это может инициировать проверку механизмов разделения данных. Платформа должна гарантировать, что новый объект корректно вписывается в существующую схему прав и фильтрации данных на уровне СУБД (RLS или разделение данных). Даже если это не вызывает пересоздания всех таблиц, этап проверки может занимать значительное время, имитируя процесс реструктуризации.
Посмотрим на ситуацию со стороны обмена данными. Если в конфигурации существуют планы обмена, в которые новый документ включается как объект состава, платформа должна подготовить таблицы регистрации изменений. Каждый план обмена имеет свои вспомогательные таблицы (например, _ChngRRef). Добавление нового типа объекта в состав плана обмена требует от платформы создания или модификации механизмов отслеживания изменений для этого типа данных, что также вносит вклад в общую длительность принятия изменений.
Важно понимать, что начиная с версии платформы 8.3.11, разработчикам доступны два механизма обновления структуры базы данных. Рассмотрим их отличия:
Традиционный механизм (v1): Создает временную копию каждой изменяемой таблицы, переносит туда данные, удаляет старую таблицу и переименовывает новую. Это максимально надежный, но крайне медленный способ. Если платформа по какой-то причине (например, из-за сложности индексов или специфики СУБД) решает использовать v1, то даже минимальное изменение вызовет полноценную реструктуризацию.
Оптимизированный механизм (v2): Старается использовать прямые команды СУБД типа ALTER TABLE. Этот метод работает в разы быстрее, так как не требует физического копирования всех строк данных. Если в одном случае вы добавили документ и процесс прошел мгновенно, а в другом — затянулся, возможно, платформа переключилась между этими режимами из-за особенностей текущей структуры базы.
Даже если ни одна пользовательская таблица не была затронута, процесс «Принятия изменений» всегда затрагивает системные таблицы базы данных, такие как Config, Params и DBSchema. Платформа выполняет следующие действия:
В больших конфигурациях один только анализ соответствия метаданных и физической структуры СУБД может занимать существенное время, которое пользователь видит в окне прогресса как «Реструктуризацию».
Если вам необходимо точно выяснить, какая именно таблица вызывает задержку, воспользуйтесь инструментом Технологический журнал (ТЖ). Настройте сбор логов для события RESTRUCT. В логе будет зафиксировано начало и окончание процесса для каждой конкретной таблицы. Пример того, что можно увидеть в логах:
Starting restructuring of table _Document123...
Creating temporary table #tt1...
Copying data from _Document123 to #tt1...
Это позволит вам увидеть, была ли это системная таблица, таблица журнала или какой-то «забытый» регистр с составным типом данных. Таким образом, реструктуризация при добавлении нового объекта — это не ошибка, а следствие глубокой связности данных в платформе 1С. Понимание этих механизмов поможет вам лучше планировать время на обновление продуктовых баз.