一般に、ユーザーを報告するためのビュー レイヤーまたはマテリアライズド ビュー レイヤーのいずれかを考えています。具体的なパフォーマンスの問題がない限り、クエリの書き換えを使用して選択したレポートを高速化するマテリアライズド ビューを時折作成することを考慮して、ビューを使用することをお勧めします。
マテリアライズド ビューを使用すると、明らかにデータを 2 回目にマテリアライズすることになりますが、その形式ではストレージの効率が低下します。これは、システム内のほとんどの領域が、非正規化されたマテリアライズド ビューとそのインデックスに割り当てられることを意味します。これにより、ディスク ベンダーから多額の請求が発生する可能性があり、SAN リソースの競合が発生する可能性があります。
また、マテリアライズド ビューは、OLTP とレポート ユーザーの間のキャッシュ領域の競合が増えることを意味します。それらは異なるオブジェクトに保存されるため、最近のアクティビティを探しているレポートは、OLTP アクティビティからのキャッシュ内のホット ブロックの恩恵を受けることができず、その逆も同様です。RAM を投入するか、レポートを非ピーク時間に移動することでこの問題を軽減できますが、これは最も効率的な解決策ではありません。ほぼ完全に履歴レポートを持っている場合、これはおそらく大したことではありません.プロセスは完全に異なるブロックに関心があるため、とにかく共有はありません.しかし、多くの運用レポートがある場合、それは重要になります.
マテリアライズド ビューも柔軟性に欠ける可能性があります。同じデータを複数の方法で提示したい場合、マテリアライズを複数回実行すると、ディスクとキャッシュの両方で実際のコストがかかり、マテリアライズド ビュー レイヤーの定期的な更新に必要な時間が長くなります。実際には、それはレポート ユーザーがデータの最小公分母ビューを取得し、IT 部門が新しいマテリアライズド ビューを作成することを望まないため、データをスライス アンド ダイスするときに車輪を再発明する必要があることを意味する傾向があります。
先に述べたように、私の好みは通常のビュー レイヤーです。これにより、データを複数回保存するコストが回避され、OLTP とレポート クエリ間でキャッシュ内のブロックを共有できるようになります。また、ユーザーにデータのさまざまなビューを提供することも比較的簡単になり、レポート対象のデータがどれほど古いかをビジネス ユーザーに通知し続ける必要がなくなります。実行したい種類のクエリが OLTP データ モデルでサポートされていないためにパフォーマンスが問題になった場合は、クエリ リライトを介してインデックスのように機能する、ターゲットを絞ったマテリアライズド ビューを作成できます。. つまり、ユーザーは通常のビューにクエリを実行でき、DBA は後で結果のすべてまたは一部を生成するマテリアライズド ビューを追加でき、オプティマイザはクエリ プランを変更して、テーブルをスキャンして何かを行うのではなく、その新しいマテリアライズド ビューを使用できます。実行時にデータを集約するようなものです。
ある時点で、レポート トラフィックを移動して、より次元の高いデータ モデルを備えた実際のデータ ウェアハウスにヒットさせたいと思うでしょう。通常のビュー レイヤーではなく、マテリアライズド ビュー レイヤーのパフォーマンスが本当に必要な場合は、ファクトとディメンションを備えた実際のデータ ウェアハウスを使用することを強く考えます。完全なマテリアライズド ビュー レイヤーで発生する可能性が高い ETL の頭痛の種と基本的に同じで、レポート用にはるかに柔軟なものが得られます。