IMO that's exactly the way to approach it -- do some tests and find out for yourself what the hit is. The person I probably learned more about normalization from was a DBA at Kraft who did not drink the Codd relational Kool Aid unquestioningly. He said normalize to 3NF first, then don't be afraid to denormalize if you have a reason to.

One thing that doesn't seem to come up often enough in proclamations about the "proper" way to store data is that there are two fundamental types of applications, OLTP and OLAP. OLAP applications are relatively static and are typically used for reporting, often against archival data. Nothing wrong there with calculating values once and storing them.

>Thanks ALL...i had the client do a few tests...generating reports w/hundreds of records and minimal processing (the account balance calculation would required minimal processing), and it was very quick....so i'm going to go the way of NOT storing.
>
>J
>
>>Since reviewing several records to get a balance can be slow, I tend to update this automatically - through triggers. In your case, since you have to postpone the updating of the balance, there might be a field of type "L" which says whether a specific transaction has been updated (has updated the grand total) or not - and a process to update those that are more than "x" days old (and mark them as updated).
>>
>>>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