私は以下のような2つのテーブルを持っています：
この構造を使用して、すべての請求額の合計を親テーブルに配置することをお勧めします。これにより、リクエストを高速化し、繰り返しの計算を回避できます（結果は後にトリガーで更新されます）請求書テーブルに）？
または、正規化されたテーブルを取得し、計算フィールドの種類をキャッシュしない方がよいでしょうか。
質問する
1136 次
2 に答える
1
これ自体は悪い習慣ではありません。ただし、実装する前によく考えてください。非正規化はパフォーマンスを向上させる可能性がありますが、常にではありません。また、保守性の面でもコストがかかります。
平均して、プロジェクトごとにいくつのサブプロジェクト請求書が存在しますか? ほんの一握りの場合、合計を計算するコストは無視できます。この場合、非正規化しないでください。
ある特定のプロジェクトについて、サブプロジェクトの請求書のリストが変更される頻度はどれくらいですか? ごくまれに、合計を事前に計算する必要があります。
逆に、サブプロジェクトの請求書のリストが「頻繁に」変更される可能性が高い場合 (合計の読み取り/計算が必要になる頻度と比較して)、合計の再計算に必要以上の時間を費やす可能性があります。
結論: 実際のボトルネックを特定する前に非正規化しないでください。実際のパフォーマンスの問題を特定したら、後でリファクタリングを考慮してアプリケーションを書き直すことは比較的簡単です。
于 2012-12-19T10:56:38.340 に答える
1
指定された構造を使用して合計を格納することに問題はありません。invoice_numberandをキーとして使用する必要invoice_dateがあるため、混乱の危険はありません。一度だけ計算する方が明らかに効率的です。基本的に、結果が必要になるたびに計算を行うのはなぜですか?
于 2012-12-19T10:47:43.387 に答える