2

SQL Server および Sybase データベースからそのような形式のデータにアクセスできる必要があります (date, productがキーです)。

date, product, dailyProfit, monthlyCumulativeprofit, yearlyCumulativeProfit

現在、私が引き継いでいるプロジェクトには、dailyProfits更新、追加、削除されるテーブルがあります...その結果、既存のコードが月間累積利益だけでなく、年間累積利益も破損しているようです。

問題を克服し、コードを掘り下げてテーブルの整合性を回復する必要がないようにするには、次のようなテーブルを用意できますか?

date, product, dailyProfit

これはINSERT、UPDATE、DELETEを受け取り、いくつかのメカニズム（トリガー？または、この小さなテーブルに平均300万行が含まれているという事実を考えると危険ですか？）を使用して、より自動化された累積合計を含む同期ビューを提供しますそして信頼できる方法...

これについてどう思いますか。

4

3 に答える 3

2

それは、使用しているデータベースとデータ使用情報に大きく依存します。事前に集計されたデータがあると、情報が古くなる可能性があるため、注意が必要です。可能な限り、「オンザフライ」計算を優先する必要があります (特にパフォーマンスが問題にならない場合)。

ここでは、探索するためのいくつかのオプションを示します。インデックス付き/マテリアライズド ビュー (リンク) または M-Olap キューブを使用して情報を事前に集計します。

于 2012-06-08T18:17:37.293 に答える
2

可能な限り、冗長なデータを保存しないようにしてください。個々の値と合計の両方を保存すると、合計が実際には個々の値の合計と一致しない可能性が生じます。これは、個々の値を読み取る関数が、保存された合計を使用する関数とは異なる結果を返すという不可解なバグにつながる可能性があります。運が良ければ、画面 A の値が画面 B の値と異なることに誰かが気づき、調査して修正することができます。しかし、ある値のセットを選択基準に使用し、別の値のセットを表示に使用するなど、より複雑な場合は、誰も気付かない可能性があります。

値の同期を維持することは、関係が何であるかによっては、プログラミングの大きな頭痛の種になる可能性があります。運が良ければ、個々の値が追加、変更、または削除されるたびに合計を自動的に更新するいくつかのトリガーを設定できる場合があるため、少なくともこれは 1 か所でのみ行われます。

しかし、ここでのキー フレーズは「実用的な場合はいつでも」です。簡単な例を挙げると、ユーザーが自分の銀行口座にアクセスするたびに、おそらく残高を見たいと思うでしょう。彼がアカウントを開設して以来、おそらく何年も前にすべてのトランザクションを合計する必要があることを表示する場合、パフォーマンス キラーになる可能性があります。

そのため、必要なときに余分な合計を保存しますが、必要な場合にのみ保存してください。冗長な合計を保存する必要がある場合は、可能な限り少ないレベルを保持してください。毎日の合計、毎週の合計、毎月の合計、年間の合計は保存しません。合計で 1 つのレベルを選択し、それを維持するようにします。おそらく、その場で毎日および毎週の合計を再計算できるように. たぶん毎月維持し、12か月を合計することで年間を計算できます。または、長期的な計算のために年次を維持するだけで、その場で計算することはできません。それはすべて、所有しているレコードの数と必要な出力によって異なります。しかし、合計が増えるたびに、同期を維持する必要があるため、潜在的な問題が 1 つ増えます。

于 2012-06-08T18:33:38.320 に答える
0

場合によります。累積合計を頻繁に要求する場合は、それらを保存することをお勧めします。これは、すべての要求で累積合計を計算すると多くのリソースが使用されるためです。

トリガーを設定して、追加時に累積値を増加させ、削除時に減少させることができます。更新すると、適切に更新されます。

同じ理由で、インターネット フォーラムでは通常、ユーザーごとの投稿数が表示されますが、もちろん投稿はリクエストごとにカウントされる可能性があります (これはパフォーマンスに大きな影響を与える可能性があります)。トリガーは、新しい投稿が追加されるとカウンターを増加させ、投稿が削除されると減少します。

于 2012-06-08T09:34:42.553 に答える