In theory your friend is right. Storing a calculated field is a violation of the relational model, which states that a field (column) should be dependent only on the record key. In practice it is acceptable to "denormalize" in cases like this if there is a significant performance gain. The way I learned it is to always normalize first -- i.e. be relationally pure -- and only denormalize in response to a performance problem.


>I'm a former Clipper programmer switch to VFP few years ago, I still keep my old Clipper style, when I tried to convert to SQLServer database, I asked another programmer for an advise. he said my database designed was bad, and it won't work with SQLServer database.
>
>The main issue with my design is I always keep calculated fields, which store how many stock onhand in store, warehouses, etc, while he said I shouldn't have any calculated fields, thus avoid record locking, if I want the figure I should recalculate them from the invoices. We have argued about this issue for a long time and I don't know who is right. I can't imaging how I can recalculate 100.000 items before printing a stock onhand report.
>
>I would like to ask for your opinion.
>
>John