"Определяемый тип" vs "составной тип" #793680

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

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

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

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

+1

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

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

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

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

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

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

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

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

> ... грубо говоря справочник аналитика, в котором реквизиты: а, б, с. так и сделали ... но почему именно "реквизиты: а, б, с", а не один составной реквизит "а, б, с"??? никогда так не делаю) в первую очередь пока из-за того, что пользователю для выбора вся эта лабудень вылезет...