Помогите разобраться, по какой причине выполняется реструктуризация в такой ситуации?

Есть регистр с измерением составного типа из типов "СправочникСсылка" и "ДокументСсылка". Добавляем в конфу новый справочник или удаляем существующий ---> при обновлении запускается реструктуризация этого регистра по причине "Attribute type CHANGED"

Реквизит с любой ссылкой представляется в БД тремя полями:
_TYPE - идентификатор типа (как для любого составного значения)
_RTRef - идентификатор таблицы БД, на которую ссылаемся
_RRRef - сама ссылка в таблице, на которую указывает _RTRef

Вроде нечего менять в структуре, разве что найти записи со ссылка этого типа (при удалении справочника) и их как-то обработать. Что тогда делает реструктуризация?

P.S. вопрос возник при спотыкании о регистр ВерсииОбъектов

> Реквизит с любой ссылкой представляется в БД тремя полями
Не всегда. Если в соответствующей коллекции метаданных только один элемент, то поле в таблице БД будет простого типа, т.е. там будет только _RRRef .

(0) > из типов "СправочникСсылка" и "ДокументСсылка"

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

при добавлении,не очень понятно,зачем
а при удалении,записи,то нужно удалить.

(1) >  Если в соответствующей коллекции метаданных только один элемент, то поле в таблице БД будет простого типа, т.е. там будет только _RRRef .

То есть можно предположить (ПРЕДПОЛОЖИТЬ), что смыслом реструктуризации может быть превращение трех полей в одно или, наоборот, одного в три? Пока других изменений не могу прикинуть.

(3) при удалении обрабатываются все записи регистра. Даже если в нем нет ссылок на удаленный справочник. Даже если он пустой.

(5) "Даже если в нем нет ссылок на удаленный справочник" - вот 1С и проверяет - нет ли ссылок.

(4) Анализ характера изменений при принятии решения о реструктуризации таблицы старым механизмом обновления конфигурации БД не делается. Поэтому при любом изменении на уровне метаданных, которое может изменить ее структуру, ее таблица БД помечается как "Нужно реструктуризировать". А дальше тупо создается новая таблица в БД и из старой все копируется в новую через универсальный код.

Но уже есть новый (оптимизированный, но сырой) механизм  реструктуризации. Там уже делается такой анализ.

анализ он делает, но иногда может и базу убить )))

(8) это всё объясняет. Спасибо )

(8) лучше без анализа при обновлении,чем с анализом,но потом еще куча анализов для восстановления.