Есть база, в которой есть 10 000 000 (10 миллионов)  документов "Заказ". Сейчас необходимо в этот документ добавить новый реквизит составного типа, что приведет к долгой реструктуризации метаданных. В будущем состав типов этого реквизита будет меняться, и для каждого такого изменения нужна будет повторная длительная реструктуризация метаданных. Что если в качестве типа данного реквизита назначить "определяемый тип", в котором назначать нужные типы. При изменении состава этого "определяемого типа" реструктуризация будет происходить также долго? Кто вкурсе, как оно устроено на физическом уровне?

добавь регистр сведений

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

чтобы не было реструктуризации - надо добавлять "сбоку", например как в (1)

(1)+1

реструктуризация будет идти относительно быстро.

лучше ПВХ и значение ПВХ

(0) добавь некоторое количество справочников-пустышек с запасом

(7) вот это "по-нашему"

(0) составной тип - это зло

Всем спасибо! Решили таки вынести это дело в отдельный справочник со своей иерархией, а там чудить с типами.


(7) :)))))))))))))))))

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

Если все же невозможно и потребуется добавлять реквизит, то моменты
1. Если сделать простой тип, а потом составной, то будет долгая реструктуризация, т.к. фактически добавляется колонка с типом и этот тип добавляется.
2. Если тип уже составной (ссылка), то добавление к нему новой ссылки уже будет проходить быстро (колонка с типом данных добавлять не будет). Рекомендую читать толстую книгу - как хранятся составные типы данных (отдельные колонки для строка, число, дата, тип ссылки + ссылка)
3. В скуле можно сделать так: перед реструктуризацией средствами вынести все данные из таблицы во временную табличку. Провести реструктуризацию. Вернуть данные средствами скуля.
Будет быстро, но требуются прямые руки, доступ к скулю + нарушение лицензии.

P.S. Кстати, один из вариантов - делать реквизит справочник и все варианты составных типов выносить в этот справочник. Зачастую так получается дешевле, чем делать под каждый элемент реквизит. Т.е. грубо говоря справочник аналитика, в котором реквизиты: а, б, с.

+11 если делать составной тип, то добавляйте только то, что нужно. Особенно ужас, когда добавляют тип ДокументСсылка.
Если потребуется брать подчиненный реквизит (например, через точку), это приведет к левому соединению со всеми таблицами, которые входят в составной тип

(11) > ... грубо говоря справочник аналитика, в котором реквизиты: а, б, с.

так и сделали (10)... но почему именно "реквизиты: а, б, с", а не один составной реквизит "а, б, с"???

(12) никогда так не делаю) в первую очередь пока из-за того, что пользователю для выбора вся эта лабудень вылезет...