How do you design the database to calculate the balance?

1) Presently I calculate the balance in the transaction table During my transaction table I've "description" and "amount" etc..

I'd adding up all "amount" values which works the user's balance.


I demonstrated this to my pal and that he stated that's a bad solution, when my database develops its likely to decelerate???? He stated I ought to create separate table to keep the calculated balance. If did this, I will need to maintain two tables, and it is dangerous, the balance table could walk out sync.

Any suggestion?

EDIT: OPTION 2: must i add an additional column to my transaction tables "Balance". now I don't need to undergo many rows of information to do my calculation.

Example John buys $100 credit, he debt $60, then he adds $200 credit.

Amount $100, Balance $100.

Amount -$60, Balance $40.

Amount $200, Balance $240.

A time-old problem which has never been stylishly resolved.

All of the banking packages I have labored with keep balance using the account entity. Calculating it quickly from movement history is unthinkable.

The proper way is:

  • The movement table comes with an 'opening balance' transaction for every single account. You will need this inside a couple of year's time whenever you have to move old actions from the active movement table to some history table.
  • The account entity includes a balance area
  • There's a trigger around the movement table which updates the account balances for that credited and debited accounts. Clearly, it's commitment control. If you cannot possess a trigger, then there should be a unique module which creates actions under commitment control
  • You've got a 'safety net' program you can run offline, which re-computes all of the balances and shows (and optionally corrects) erroneous balances. This is helpful for testing.

Some systems store all actions as positive amounts, and express the loanOrmoney by inverting the from/to fields or having a flag. Personally, I favor a credit area, a debit area along with a signed amount, this will make reversals much simpler to follow along with.

Observe that these techniques is applicable both to cash and investments.

Investments transactions could be much more difficult, specifically for corporate actions, you will have to accommodate just one transaction that updates a number of buyer and seller cash balances, their security position balances and perhaps the broker/depository.

You need to keep current balance and it current whatsoever occasions. The transaction table is simply a record of what is happening previously and should not be applied out a higher frequency simply to fetch the present balance. Take into account that many queries don't simply want balances, they would like to filter, sort and group by them, etc. The performance penalty of summing every transaction you have ever produced in the center of complex queries would cripple a database of modest size.

All updates for this set of tables ought to be inside a transaction and really should make sure that either everything remains synchronized (and also the account never overdraws past its limit) or even the transaction comes back. Being an extra measure, you can run audit queries that take a look periodically.

Your friend is wrong and you're simply right, and that i would counsel you don't change things now.
In case your db ever goes slow due to this, and once you have verified all of the relaxation (proper indexing), some denormalisation might be useful.
You can then put a BalanceAtStartOfYear area within the Accounts table, and summarize only this season records (or any similar approach).
However I would likely not recommend this method upfront.

You'll need some denormalisation inside your database to keep some historic data for report generation reasons. That will entails some datawarehousing deal with. It is best to store your historic data by datetime format inside a separate table, in the close of the accounting books each and every year-finish, in particulars or by balance. This is often automated by calling a UDF or perhaps a trigger.

By shifting out a few of the past data, you won't just free-up some space for storage, but making your operational server faster and efficient. accountingdes.com responded.