Как избежать долгой реструктуризации при добавлении составного или определяемого реквизита в таблицу с миллионами записей 1С?

При сопровождении высоконагруженных и объемных информационных баз 1С (например, когда документ Заказ содержит более 10 000 000 записей) любое изменение структуры метаданных может привести к многочасовому технологическому окну из-за тяжелой реструктуризации таблицы СУБД. Проанализируем, как работают определяемые и составные типы на физическом уровне, с какими подводными камнями сталкивается разработчик и какие архитектурные альтернативы позволяют вносить изменения без остановки работы пользователей.

Физическое устройство определяемых и составных типов на уровне СУБД

Выясним причину, почему замена составного типа на объект метаданных ОпределяемыйТип не решает проблему длительной реструктуризации. На уровне СУБД объект ОпределяемыйТип не существует как отдельная сущность — это исключительно инструмент разработчика в дереве метаданных конфигуратора для централизованного управления типами. Во время сохранения конфигурации базы данных платформа 1С автоматически разворачивает определяемый тип в соответствующий набор типов (простой или составной).

Рассмотрим подробнее, как платформа 1С транслирует составной тип данных в физические колонки таблицы базы данных:

1. Хранение ссылочных типов: если составной тип состоит только из ссылок на различные справочники и документы, платформа создает в таблице СУБД служебное поле кода типа (_TYPE) и поле бинарного идентификатора ссылки (_RTRef / _RRRef). При добавлении еще одной ссылки в состав существующего ссылочного типа состав физических полей может не меняться, однако изменение схемы метаданных все равно требует валидации данных платформой.
2. Хранение примитивных типов: если в реквизит включаются примитивные типы (число, строка, дата, булево) совместно со ссылками, платформа 1С создает под каждый примитивный тип отдельную колонку в СУБД (например, _Number, _Date, _String). Каждое расширение состава реквизита новым примитивным типом приводит к физическому добавлению новых колонок и перестроению таблицы.
3. Опасность определяемого типа при реструктуризации: если реквизит ссылается на ОпределяемыйТип, который используется в десятках других объектов конфигурации, любое изменение состава типов в этом определяемом типе запустит параллельную реструктуризацию всех связанных таблиц в базе данных, что многократно увеличит общее время простоя.

Проблемы производительности составных типов в запросах и индексах

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

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

Если обращение через точку к составному типу неизбежно, оптимизируем запрос с помощью явного приведения типов через оператор ВЫРАЗИТЬ, чтобы исключить лишние соединения:

ВЫБРАТЬ
    Заказ.Ссылка КАК Ссылка,
    ВЫРАЗИТЬ(Заказ.РеквизитАналитики КАК Справочник.Контрагенты).ИНН КАК КонтрагентИНН
ИЗ
    Документ.Заказ КАК Заказ
ГДЕ
    Заказ.Дата МЕЖДУ &ДатаНачала И &ДатаОкончания

Архитектурное решение 1: Вынос аналитики в подчиненный регистр сведений

Разберем по шагам наиболее надежный способ добавления новой аналитики без затрагивания основной таблицы документа с 10 миллионами записей. Мы можем создать независимый или подчиненный регистр сведений.

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

Архитектурное решение 2: Выделение единого справочника-аналитики

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

1. В документе создается реквизит со ссылкой на справочник АналитикаЗаказов.
2. Все вариативные реквизиты, комбинации значений или составные типы размещаются внутри этого справочника.
3. Количество элементов в справочнике аналитики обычно на порядки меньше (сотни или тысячи записей вместо 10 миллионов), поэтому любые последующие изменения его состава метаданных проходят за доли секунды.

Архитектурное решение 3: План видов характеристик (ПВХ) и подсистема БСП

Для задач, где состав реквизитов постоянно меняется бизнес-пользователями, используем стандартный механизм дополнительных реквизитов и сведений на базе ПланВидовХарактеристик:

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

Использование механизма фонового обновления в 1С 8.3

Если бизнес-требования категорически требуют наличия реквизита непосредственно в самом документе, проанализируем возможности современных версий платформы 1С:Предприятие 8.3 по снижению времени простоя базы:

1. Используем механизм фоновой реструктуризации таблиц при обновлении конфигурации базы данных.
2. Платформа запускает фоновую обработку данных частями, не накладывая длительную исключительную блокировку на всю таблицу Заказ, что позволяет пользователям продолжать работу.
3. Финальная фаза применения изменений занимает короткий промежуток времени, достаточный для штатного технологического окна.