Доброго дня, коллеги.
такая ситуация(сложилось исторически :) ):
есть несколько измерений
1. Клиенты по ЛС >2млн. членов, 5 уровней
2. Клиенты юр. типу {Юр.лицо; Физ.лицо}
3. Клиенты по типу финансирования {Комерческий, Бюджет, Льготник....} - 10 членов
4. Клиенты по ИНН ~40тыс. членов, 5 уровней, Parent-Child.
5. Клиенты еще по какому-то ттипу {....} - 50 членов

Есть желание построить ОДНО измерение "Клиенты по ЛС" (2 млн. членов) и от него на основе свойств(либо табличной связи) построить остальные измерения как виртуальные.

Как вы считаете, есть смысл подобной перестройки и самое главное не вызовет ли это сильного замедление работы/времени отклика при анализе данных на клиенте?

Dmitry Biryukovну а тогда зачем их делать виртуальными?
м.б. для того, чтобы явно указать, что они все взаимозависимы и сервер, при подсчете агрегатов, не строил их пересечения.
В depends можно укзазать только одно измерение, а так получается несколько.

backfireЕсли время отклика станет критичным, то никто не запрещает включить аггрегацию на виртуальные измерения, которая по умолчанию выключена.
А где это MSAS2K указывается?
построил вирт.измерение, в списке свойств ничего похожего найти не могу.

Dmitry Biryukov O_Vital backfireЕсли время отклика станет критичным, то никто не запрещает включить аггрегацию на виртуальные измерения, которая по умолчанию выключена.
А где это MSAS2K указывается?
построил вирт.измерение, в списке свойств ничего похожего найти не могу.в куб зайди
Св-во Aggregation Usage?

И всё-таки, есть смысл перестраивать структуру и завязываться на виртуальные измерения или оставить всё как есть?
Кто-нибудь на практике сталкивался с таким?

Еще интересует, как будет себя вести виртуальное измерение состоящее из 40 тыс. членов, построенное на основе другого, у которого 2млн. членов?