OLTPデータベース内の非正規化テーブル
私の会社には、かなり正規化されたmssqlサーバーデータベースを中心とした製品があります。この時点で、ユーザーに適切にデータを表示するために、よりフラットな方法でデータを必要とするいくつかのレポートとWebアプリケーションがあります。今日、ビューとストアドプロシージャを使用して、レポートとWebアプリに必要なフラット化されたデータモデルを提供しています。
現在、いくつかのビューでは、ビュー内で実行される集約データと結合の量が原因で、パフォーマンスの問題があります。代わりに、レポートとWebアプリケーションの両方のパフォーマンスを最適化できる非正規化テーブルを提供することを考えました。これらの非正規化テーブルは、一定の間隔で構築されるか、基になるoltpテーブルが更新されるときに維持されます。
これは一般的なことですか？これらのテーブルを最新の状態に保つだけのパフォーマンスについては、問題が発生しますか？このような種類のテーブルを作成するには、どのメカニズムが最適ですか？これを行うには、これらの非正規化されたテーブルよりも良い方法はありますか？
あなたが考えていることは比較的一般的であり、データを前処理することは確かにレポートとWebページのパフォーマンスに役立ちます。これの「コスト」は、前処理に時間がかかるため、非正規化テーブル（これをミニOLAPデータウェアハウスと考えることができます）が完全に最新の状態になることはありません。
これは大きな問題ではなく、ユーザーが理解する必要がある問題です。 （例-「私はxyzトランザクションを終了したばかりで、レポートには含まれていません。」）
最新のトランザクションを必要とするレポートには、前処理された「OLAP」データの代わりに、ライブデータの少なくともいくつかの要素を含める必要があります。
これは、関係を説明する一般的なリンクです。 http://datawarehouse4u.info/OLTP-vs-OLAP.html
このWebページでは、OLTP/OLAPの細分化のいくつかのニュアンスについても説明していますが、説明に驚くほどのことはありません。
可能であれば、非正規化テーブルを作成しないようにします。歴史的に、これは私にとって管理上の問題につながりました。データベースエンジンがサポートしている場合は、最初にパフォーマンスの問題があるビューにインデックスを作成し、次にNOEXPANDヒントを使用してビューを拡張することを目的としたビューのインデックスを使用するように実行プランを強制できます。
SQL Serverでそれを行う方法についてのドキュメント http://msdn.Microsoft.com/en-us/library/ms187373.aspx
ただし、ビューでのインデックスの作成は常に可能であるとは限りません。いくつかの制限があります。 http://technet.Microsoft.com/en-us/library/aa933148%28v=sql.80%29.aspx