should the user's Account balance be stored in the database or calculated dynamically?

Question

Should the user's Account balance be stored in the database or calculated dynamically?

For accurate results calculating it dynamically make sense but then it might be a problem, when there are many user's and the database grows very large?

Transaction

• Id (PK)
• AccountId
• Type
• DateTime
• Amount
• etc..etc...

AccountBalance

• TransactionId (PK/FK)
• BalanceAmount

Punk

How about calculating it dynamically and then storing it in the database. This would mean that the user could review his balance over time. – Augment

Keep a log of changes and keep one 'soft' record for actual data. The soft record is simply an up to date field with most balance data. Update all the fields in a single transaction and there you go. For a simple game I would just keep a single 'Amount' field. – Hortenciahortensa

Answer 1

In order to keep accurate auditing you should make record of every transaction that affects the users account balance. This means you can calculate the balance dynamically, however for performance reasons I would have the balance stored as well. To ensure the balance is correct though, I would have a daily job run that recalculates the balance from scratch.

Matronna

Answer 2

You need to ask yourself a few questions: 1) Who will OWN the calculation? 2) Who will NEED the result?

Now if the owner of the calculation is the only one who will need it - or if anyone else who needs it will get it from the owner, then there is no need to store the calculation.

However, in most applications that actually run for a long time, the calculated result will probably end up being needed somewhere else. For instance, a reporting application like SQLReportingServices will need the result of the calculation, so if the owner of the calculation is a web application, you have a problem. How will reporting services (which talks to the database only) get the result?

Solution in that case - either store the calculation OR make the database the owner OF the calculation and have a sql function that returns the result.

Personally, I tend to go for the non-purist approach - I store calculated results in the database. Space is cheap, and response time is faster on a read than on a read+function call.

Badger

Answer 3

I think this is a good question. Calculating every time is obviously easy to do but would probably result in a lot of needless calculations with the resultant performance hit.

But storing the current balance in some other table can lead to the issues in data concurrency, where the data the builds the aggregate is modified out of sync with the aggregate.

Perhaps a happy medium is to have a sql trigger on the transaction table that updates the aggregate value on an insert or update for that user.

Eatton

Answer 4

the current balance is already available! it is the balance in the last transaction for the account:

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

the balance has to be calculated and stored as part of every transaction otherwise the system won't scale ... also if you don't store the balance you have no checks and balances (as in balance must equal previous balance plus new credits less new debits)

Interlinear

Answer 5

1. If your application is not retrieving data from database for balance calculation while you need the balance, I will suggest that you should calculate the balance or else store in database.

2. If you need updated balance frequently and it is dynamically change based on more than one table then you should have table view instead of trigger.

Civet