14

ユーザーの口座残高をデータベースに保存するか、動的に計算する必要がありますか?

正確な結果を動的に計算することは理にかなっていますが、多くのユーザーがいてデータベースが非常に大きくなると、問題になる可能性がありますか?

取引

  • ID (PK)
  • アカウントID
  • タイプ
  • 日付時刻
  • 額
  • などなど…

勘定残高

  • トランザクション ID (PK/FK)
  • 残高
4

5 に答える 5

11

正確な監査を維持するために、ユーザーのアカウント残高に影響を与えるすべての取引を記録する必要があります。これは、残高を動的に計算できることを意味しますが、パフォーマンス上の理由から、残高も保存します。ただし、残高が正しいことを確認するために、残高をゼロから再計算する毎日のジョブを実行します。

于 2011-06-14T10:05:47.257 に答える
2

これは良い質問だと思います。毎回計算するのは明らかに簡単ですが、おそらく多くの不要な計算が発生し、結果としてパフォーマンスが低下します。

ただし、現在の残高を他のテーブルに格納すると、データの同時実行性の問題が発生する可能性があります。この場合、集計を構築するデータが集計と同期されずに変更されます。

おそらく、そのユーザーの挿入または更新の集計値を更新するSQL トリガーをトランザクション テーブルに設定するのが良いでしょう。

于 2011-06-14T10:08:46.420 に答える
1

いくつかの質問を自問する必要があります: 1) 誰が計算を所有しますか? 2) 誰が結果を必要としますか?

計算の所有者だけがそれを必要とする場合、またはそれを必要とする他の誰かが所有者から計算を取得する場合、計算を保存する必要はありません。

ただし、実際に長時間実行されるほとんどのアプリケーションでは、計算結果が別の場所で必要になる可能性があります。たとえば、SQLReportingServices のようなレポート アプリケーションは計算結果を必要とするため、計算の所有者が Web アプリケーションである場合、問題が発生します。レポート サービス (データベースとのみ対話する) はどのように結果を取得しますか?

その場合の解決策 - 計算を保存するか、データベースを計算の所有者にして、結果を返す sql 関数を用意します。

個人的には、純粋主義者ではないアプローチを採用する傾向があります。つまり、計算結果をデータベースに保存します。スペースは安価であり、応答時間は読み取り + 関数呼び出しよりも読み取りの方が高速です。

于 2011-06-14T10:05:32.453 に答える
1

現在の残高はすでに利用可能です！これは、アカウントの最後のトランザクションの残高です。

select top 1 [Balance]
from dbo.Trans
where [AccountID] = @AccountID
order by [TranID] desc

残高は、すべてのトランザクションの一部として計算および保存する必要があります。そうしないと、システムはスケーリングしません...また、残高を保存しない場合、小切手と残高はありません（残高は、以前の残高に新しいクレジットを加えたものと等しくなければならないため）新しい借方）

于 2011-06-14T11:14:19.390 に答える
0

  1. 残高が必要なときにアプリケーションが残高計算のためにデータベースからデータを取得していない場合は、残高を計算するか、データベースに保存することをお勧めします。

  2. バランスを頻繁に更新する必要があり、複数のテーブルに基づいて動的に変更される場合は、トリガーではなくテーブルビューを使用する必要があります。

于 2011-06-18T20:33:55.800 に答える