FRoST86,

SSAS?

размер измерения это не настолько мелкая проблема, внутренние crossjoin на многомилионные количества элементов производительность убивают довольно серьёзно, кроме того измерения хранятся в оперативке ..

основной вариант - ETL до процессинга, часто (когда особого контроля за DWH/DMT нет) то используют пост-процессинг (подмена источника измерения/переименование основного View) и процессинг (ProcessUpdate) от туда.
обычно эти данные в SQL заполняются из куба (через nonempty.. нужного ключа) - у меня на это стоят отдельные Agent-Jobы последним шагом
хотя если только ради фильтрации - то можно и на клиенте поднастроить.

StarikNavy,

Клиенты разные бывают, т.е. не только Excel, так что тот-же запрос с nonempty на нужные меры из комбинации групп {}
а с Excel - верно, именно на уровне фильтров не получится - с данными да, null можно скрыть, а сам фильтр не настроишь


ShIgor,

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

тут уже вопрос выбора разумного баланса: например 500 пользователей будут на 50-200% (в оптимистичном сценарии) больше времени тратить на получение данных только за счёт того что 1-5 пользователей смогут покопаться в справочниках.