>In my VFP app, I have a certain important table that is the header table for what we call a Job. Each Job will have many collections of records in various other tables that are associated with it: Time records, Material records, Invoice records, etc. So, the data is fairly well normalized and granular and that is good. However, the original architect of our system decided to keep track of the totals of each of these collections in its own field in the main Job table so that he could easily display or report things like "Total Material Cost" or "Total Labor Cost" or "Total Invoiced Amount", etc. So, all the forms and methods that manage the individual related collections, are also burdened with keeping the reference totals in the Job header table up to date. Kind of a nightmare, and creates a lot of coding that really should not even be necessary. And, despite all the best coding effort I can muster up, the reference totals are sometimes not correct, so I have made another maintenance prg to audit and correct the incorrect data.
>
>Am I right that this is a classic bad example of how to manage these reference totals? The values are indeed needed often throughout our system, but I am convinced that this is a bad way to do it.
>
>Now then, before I get too far into reworking how this is handed in my system, would some of you smart folks please tell me how you handle this common issue.

Performance is the only issue here, and properly normalized data should not have performance problems, unless number of detail records is big, e.g. hundred thousands. Anything less should not require having totals in the parent table especially if it is used for reference purposes only. There are situations when 'totals' are used for functionality purposes, it may indicate some problems with design.
Complicated calculations, except performance impact, should not be considered as an excuse. If total number is used often on forms/reports then application may have separate method/procedure to do it in uniformed, easily maintainable, way.