私はいくつかの大きなキューブがあるプロジェクトに取り組んでいます。使用されているテクノロジーは SSAS です。何百ものレポートがあり、多くの計算がレポート定義にあります。レポートで計算を行うのは正しい方法だとは思いません。テストが複雑になります。より良い解決策は、OLAP で計算を行うことだと思います。しかし、開発者は、キューブがより大きく複雑になるにつれて、MDX クエリが何年も実行されると不満を漏らしています。私の考えは、たくさんの小さな立方体を持ち、その中で計算を行うことです。
それは良い考えですか？レポートの値のテストの複雑さを軽減する方法について、別のアイデアはありますか?
MDX クエリのパフォーマンスは、主にキューブ アーキテクチャに依存します。適切な階層とビジネス ロジックとの適切な相関関係があれば、キューブのサイズを気にする必要はありません。
パーティションで最大 2000 万に達している限り、時間軸に基づいて 2 つに分割し、集計を設計すれば問題ありません。かなり複雑な MDX を実行する 7 億以上のデータ パックをホストするキューブがあり、パフォーマンスの問題はありません。同時に、1,000 ～ 2,000 万のデータソースしかないキューブは、アーキテクチャがより複雑で最適化されていないため、遅くなる可能性があります。
計算メンバーは、使用しなければキューブのパフォーマンスに影響しません。それらは記憶域を必要とせず、Calculatd メンバーにヒットするクエリを使用してキューブにクエリを実行した場合にのみ計算されます。したがって、計算されたメンバーを追加し、レポートで計算を使用し続けるとしましょう。違いはありません。使用されるのを待っています。これはテストに適しています。レポートのコピーを作成し、両方を並行して実行して結果をテストできます。
それが役立つとは思いません。ソリューションが複雑になることもあります。私はそれから離れていると言うでしょう