Почему удаление значения перечисления вызывает долгую реструктуризацию базы 1С и как это предотвратить

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При внесении изменений в структуру метаданных конфигурации 1С разработчики нередко сталкиваются с ситуацией: удаление всего одного неиспользуемого значения перечисления приводит к многочасовому обновлению информационной базы. При этом процесс затрагивает таблицы документов, справочников и регистров, в которых данный тип данных, казалось бы, вообще не фигурирует. Рассмотрим подробно, почему платформа инициирует масштабную реструктуризацию и как оптимизировать данный процесс.

Причины масштабной реструктуризации таблиц

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

  1. Наличие составных типов данных в объектах конфигурации. Если в метаданных используются реквизиты с широким составным типом (например, содержащие ЛюбаяСсылка или ПеречислениеСсылка), платформа включает данные таблицы в контур реструктуризации. Любое изменение в составе входящих в составной тип типов данных требует пересмотра описания колонок на уровне СУБД или файла .1CD.
  2. Общие реквизиты и критерии отбора. Наличие общих реквизитов с составным ссылочным типом данных или критериев отбора автоматически распространяет проверку типов на все связанные с ними объекты метаданных.
  3. Графы журналов документов и Планы видов характеристик. Если документ входит в журнал документов, где есть графа составного типа, или ссылается на ПВХ с широким диапазоном типов значений, платформа обязана обновить метаописание структуры хранения этих документов.
  4. Особенности движка реструктуризации на платформе 8.2. На старых версиях платформы (8.2 и ранних сборках 8.3) применялся алгоритм безусловного физического пересоздания таблиц. Платформа создавала временную копию таблицы, построчно переносила данные с валидацией типов и заменяла исходную таблицу. При этом предварительная быстрая проверка реального наличия удаляемого значения в записях не выполнялась. В файловом режиме это приводило к колоссальным временным затратам из-за последовательной перестройки страниц файла базы.

Способ 1. Мягкое удаление и отказ от физического изменения метаданных

Разберем наиболее безопасный и быстрый практический подход, не требующий тяжелой реструктуризации таблиц базы данных. Если значение перечисления стало неактуальным, его не обязательно удалять из дерева метаданных конфигуратора физически.

  1. Переименуем удаляемое значение перечисления в конфигураторе, добавив явный префикс (например, Удалить_Значение или НеИспользуется_Значение). Синоним также можно изменить на (Не используется).
  2. Исключим возможность выбора этого значения пользователями в режиме «1С:Предприятие». Для этого программно настроим свойство СписокВыбора у соответствующих элементов форм документов или справочников.

Посмотрим на пример программного исключения устаревшего значения из выпадающего списка на форме:


// Ограничиваем список доступных значений перечисления на форме
ЭлементФормы = Элементы.ВидОперации;
ЭлементФормы.РежимВыбораИзСписка = Истина;
ЭлементФормы.СписокВыбора.Очистить();

Для Каждого ЗначениеПеречисления Из Метаданные.Перечисления.ВидыОпераций.ЗначенияПеречисления Цикл
    Если Не Найти(ЗначениеПеречисления.Имя, "Удалить_") = 1 Тогда
        ЭлементФормы.СписокВыбора.Добавить(Перечисления.ВидыОпераций[ЗначениеПеречисления.Имя], ЗначениеПеречисления.Синоним);
    КонецЕсли;
КонецЦикла;

Такое изменение метаданных затрагивает только имена и синонимы, благодаря чему обновление информационной базы применяется за несколько секунд без изменения структуры таблиц хранения данных.

Способ 2. Предварительный поиск и очистка ссылок

Если удаление значения из метаданных строго необходимо, перед сохранением конфигурации обязательно проверим ссылочную целостность, чтобы избежать появления битых ссылок вида Объект не найден. Разберем, как найти и очистить ссылки программно:


// Поиск мест использования удаляемого значения перечисления
МассивДляПоиска = Новый Массив;
МассивДляПоиска.Добавить(Перечисления.ВидыОпераций.УстаревшееЗначение);

ТаблицаСсылок = НайтиПоСсылкам(МассивДляПоиска);

Для Каждого СтрокаСсылки Из ТаблицаСсылок Цикл
    // СтрокаСсылки.Данные содержит ссылку на объект, где используется значение
    Сообщить("Найдено использование в объекте: " + Строка(СтрокаСсылки.Данные));
КонецЦикла;

После выявления всех объектов заменим устаревшее значение на актуальное или очистим реквизит перед удалением свойства в конфигураторе.

Способ 3. Переход на актуальные версии платформы 8.3

Выясним причину разницы в скорости работы между платформами. Начиная с релизов платформы 8.3, механизм реструктуризации был кардинально переработан и оптимизирован:

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

Если проект позволяет, рекомендуется выполнять реструктуризацию и обновление конфигурации на актуальных версиях платформы 8.3. Даже при включенном режиме совместимости с более старыми версиями, оптимизированный движок реструктуризации платформы отрабатывает в разы быстрее, избегая избыточных многочасовых блокировок таблиц.

Способ 4. Оптимизация состава типов в метаданных

Для предотвращения избыточных реструктуризаций в будущем проанализируем конфигурацию на наличие слишком широких типов данных:

  1. Проверим реквизиты документов, справочников и общих реквизитов. Избегаем необоснованного использования типов ЛюбаяСсылка или включения всех перечислений в составной тип.
  2. Проверим графы используемых журналов документов. Ограничим типы данных только теми объектами, которые гарантированно выводятся в журнале.
  3. Сузим состав типов в Планах видов характеристик до строго необходимого перечня прикладных объектов.

Исключение избыточных составных типов локализует изменения: при корректировке конкретного перечисления платформа будет реструктурировать исключительно те объекты, где это перечисление действительно задействовано.

← На главную