キューブに多数の計算メンバーを追加することによるパフォーマンスへの影響があるかどうか疑問に思っています。一方で、一度定義したものを一元的に配置し、テストして、MDX をサポートしていないクライアントから使用できるようになっていると便利です。一方、追加するこれらのメンバーの一部はあまり頻繁に使用されない可能性があるため、それらを必要とする可能性のある 1 つまたは 2 つのレポートにインライン化することができます。
不要なメンバーがぶらぶらしているという混乱は別として、計算されるメンバーの数をできるだけ少なくする必要がありますか? キューブの処理時間は増加しますか? これらの計算メンバーを使用しないクエリは遅くなりますか?
計算されるメンバーは、処理やその他のクエリにはほとんどまたはまったく影響を与えません。好きなだけ追加してください！
その理由は、キューブで定義されているだけで、実際には実行時に評価されるためです。したがって、それらによって速度が低下したり影響を受けたりするクエリは、それらを使用するクエリだけです。この理由から、ネイティブメンバーよりも少し遅く返されることを期待してください.
計算されるメンバーが非常に頻繁に使用される場合は、キューブの実際の部分にするあらゆる機会を探してください。また、scopeステートメントを学び、愛してください。scopedの計算されたメンバーは実行時に計算されますが、scopeステートメントは既製の実行計画を提供するため、より高速になる傾向があります。多くの場合、DSV でメンバーを作成してから、scope大量の計算メンバー用に作成します。
計算をリレーショナル モデルに戻すことができるときはいつでも、MDX クエリのパフォーマンスが向上します。だけでなく、処理パフォーマンスに悪影響を及ぼします。
行内 SQL ロジックを使用して一部のメジャーを事前計算できる場合は、これらをデータ ソース ビューでメジャーとして公開します。ストレージ エンジンは集計を作成できるため、式エンジンの作業は少なくなります。基本的に、重労働をSQLに押し下げています。これは、静的な計算と変換係数、および単純な算術演算などに対して非常にうまく機能します。
もう 1 つできることは、エンド ユーザーが非表示として使用してはならない中間計算メンバーを作成することです。これはパフォーマンスに影響しません。ただし、エンド ユーザーの観点からキューブを整理します。