А почему не построить виртуальный куб ? Или я чего-то упустил ?

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

backfireЯ тоже сначала строил виртуальный куб, но проблема или неудобство было в том, что все меры, которые есть и в плане и в факте (сумма продаж, например) надо было заменить Calculated Member, со всеми вытекающими последствиями для любимого NonEmptyCrossJoin и т.п.
Virtual cubes для того и придуманы чтобы сливать данные с разными гранулярностями в один куб. А partitions придуманы для того чтобы сливать вместе данные из разных источников, но с одинаковой гранулярностью. Ваш метод аннилирует идею работы с разными гранулярностями, т.к. он урезает большую таблицу до гранулярности маленькой. А что если в маленькой есть измерение которого нет в большой ? А что если по Actual надо делать настоящий детальный анализ - идти в другой куб. Одним словом мне вся эта идея не нравится - она идет против дизайна AS2K.
Что касается проблем с NonEmptyCrossJoin - то эти проблемы все решаемы, да и наверное Zohar не пользуется такими "оптимизациями" - так что он может воспользоваться правильным подходом а не делать hacks.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

Ну я согласен, иногда надо делать хаки чтобы выжать performance - это собственно наша вина, performance должен быть всегда супер без всяких хаков, но мы тоже не идеальны. Просто если Вам пришлось в какой-то конкретной ситуации применить хак - то это не означает, что все остальные тоже должны его применять, скорее всего у них ситуация другая и от этого хака им будет только хуже.
Так что Zohar - мой совет - виртуальный куб - но решать конечно Вам.

P.S. backfire: А что Вам теперь мешает ставить в фильтр NonEmptyCrossJoin настоящий measure, а не calculated member с ValidMeasure ?

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

backfireЯ не понял, что значит "теперь"?
Ну после того как мы починили баг в NonEmptyCrossJoin на virtual cubes, когда measures в фильтре, который Вы на этом форуме зарепортили несколько месяцев назад.

ZoharВопрос к Моше - вообще можно ли как-то обойтись без создания аналитических marts ? А использовать - таблицы с фактами и индексами и справочники вокруг них, например - проблема многих аналитиков - трудность управления метаслоем данных, поэтому идут по самому простому варианту - делают одну общую view на оперативных серверах, закладывают все измерения из справочников и на ней строят кубы, потом жалуются на производительность - как кубов, так и времени построения. Как грамотно ? Сначала сделать shared dimencions - наиболее общие измерения для всех ? Но как потом привязать к таблице с фактами ?
Я не очень понял вопрос, наверное у меня с терминологией проблемы - аналитические marts, справочники и метаслои данных - мне это все незнакомые понятия :(

ZoharПопутно еще вопрос к Backfire и Mosha к политике построения справочников - как лучше всего делать - сделать как можно больше Shared Dimension и использовать для всех кубов ? А в таблицах фактов иметь только индексы ?
Да - это классический data warehouse.

ZoharВообще - для чего предполагалось подобное разделение на Shared Dimension и local Dimensions ?
Private Dimensions давали две основные вещи:
1. INNER JOIN с fact table - т.е. members для которых нет записей не попадают в измерение
2. Процессить fact table & dimensions in single scan
3. Local cubes (там всегда private dimensions)

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

backfireВы пообещали это сделать в sp4
SP4 не за горами. SP4 Beta уже по моему вышла или выйдет на днях.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

FpmipЯ сталкивался с ситуацией, когда измерения с disabled уровнями работали неоправданно долго в сравнении с вариантом, когда эти уровни были просто удалены.
Это интересно - у Вас не сохранилось repro для этой ситуации ? Потому что внутри engine, disabled levels проимплементированы так как будто их и не было.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

FpmipRepro действительно есть.
(Точнее, речь идет о свойстве Visible, а не Disabled уровня, поскольку надо было скрыть промежуточный уровень, чего Disabled сделать не позволяет).
Спасибо - это действительно большая разница сделан level disabled или просто unvisible. Как я говорил выше - disabled level, это все равно как его и не было, а вот unvisible - он есть, только в schema rowsets его не видно. Поэтому разница в производительности в данном случае обьяснима.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights