I never store account balances unless I see a performance problem. That doesn't look like the case here. Years ago I wrote an accounting app that stored balances for customers, vendors and such. This ended up creating all kinds of problems.

>Hi,
>
>I have a table of "transaction" entries (deposits and withdrawals) for member accounts. Entries may be voided/reversed, in which case they do not affect the account balance.
>
>I have been thinking that i would STORE the account balance.
>
>Two systems will be accessing the account, creating entries and calculating and displaying the account balance. The first system (Social Security) will be making deposits and withdrawals, and the other system (Provider) will be looking at the account balance, and making withdrawals.
>
>The maximum number of deposits would probably be something like 4x/year...so even after 10 years, we're only talking about roughly 40 deposits.
>
>Now my client wants to, for certain deposits, delay the inclusion of the amount in the account balance, by a number of days (to insure that the deposits paid by checks do not bounce).
>
>I was thinking that i would store an "effective date" in these types of deposit transaction. So that means that we have an "account balance" and an "effective account balance." Eventually either the delayed deposit will become effective, or it will be reversed if the check bounces.
>
>But now i'm rethinking the whole thing....should i be storing the account balance? or just always calculate the "account balance" and the "effective account balance" on the fly. It seems that i DO have to always calculate the "effective account balance" on the fly in any case. Or have a daily automatic routine to check all entries and update the account balance.
>
>Would appreciate any ideas/input. Thanks! J