1

現在、データベースから取得した膨大な量の情報を集計する「レポート」をアプリケーションに実装しています。テーブルの各セルは別のテーブルの合計から取得され、各セルは別のテーブルの合計から取得されます。
レポートは常に最新のデータをユーザーに表示する必要があります。ソフトウェアおよびレポートのどこかで変更される各データは最新である必要があります。

SQL が生成されすぎてしまいます。

動作する中間結果とテーブルを (DB に) キャッシュしようとしました。しかし、データを変更できるアプリ内のどこでも、recomputeCache()あまりにも多くの場所で呼び出しが終了しているキャッシュを再計算する必要があります (これは絶対に最新のレポートを維持するためです)。

DBMSトリガーは機能する可能性があります：次のものを計算するテーブルのトリガー、次のものを計算するトリガーを保持するなど。
しかし、トリガーが怖い：

  • 複雑さはどうですか？コンピューティングを実行するコードは非常に大きく、「スマート」です。200 行の .NET は構文糖衣でいっぱいで、500 行の PL/SQL になります。
  • 保守性はどうですか？PL/SQL の検索、読み取り、理解、変更、デバッグなどが難しくなりませんか?
  • ビジネス ロジックのカプセル化についてはどうでしょうか。このコンピューティングはビジネス ロジック層に属するべきではないでしょうか。

「典型的な」ソフトウェアキャッシング（そして、スマートキャッシュ再計算戦略を見つけようとします）とトリガーベースのテーブル再計算（そして、ソフトウェアのベストプラクティスと保守性を犠牲にするかもしれませんか？）のどちらかを選択するのに役立つアドバイスを聞いています...

ありがとうございました ！

4

1 に答える 1

0

あなたのレポートのために、私は最初にビューを使用しようとします。ビューは、基になるテーブルの最新データへの単なるビューとして、常に最新になります。これにより、指摘したトリガーに関連する複雑さといくつかの頭痛の種を減らすことができます。

例：

CREATE VIEW report AS
SELECT 'sales' AS name, (SELECT sum(sales) FROM sales) AS value
UNION ALL
SELECT 'expenses' AS name, (SELECT sum(expenses) FROM expenses) AS value

ビューのパフォーマンスが十分でない場合は、実際にトリガーを調べて、すべてのレコードを再読み取りすることなく、合計を集計することについて賢くすることができます。しかし、私はあなたの最も単純なオプションとして最初にビューから始めます。

于 2012-11-14T18:54:07.227 に答える