[AccessD] Programming

One of the basic rules of data normalisation is not to store dependent 
values.
Here is an article by Allen Brown on a practical example of the pro's 
and cons.

Inventory Control: Quantity on Hand
http://allenbrowne.com/AppInventory.html

Bobby Heid wrote:

>I agree with most of what the others say.  
>
>Sometimes it is very expensive (resource wise) to calculate a value.  I
>store the values in this situation.
>
>Another is when you have to store a value as it was calculated at that time
>(unless you store the values used to make the calculation).  We have an app
>that calculates deducts on payroll.  There are many places in the system
>where the parameters used to calculate the value can change.  But they do
>not want the value to be recalculated unless they manually cause a
>recalculation.  For that reason, the value is stored in the database.
>
>Bobby
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Griffiths,
>Richard
>Sent: Friday, May 13, 2005 3:50 AM
>To: AccessD
>Subject: [AccessD] Programming
>
>
>Hi Group
>
>A general programming question.  Would you ever store calculated values in a
>table.  My example is this...
>
>I have a Timesheetline table recording jobstart, jobend times/dates etc. Do
>I store jobtotalhours in the table and do I store Client charge and
>EmployeePaid amounts.  I would not normally store calculated values in a
>table but as these calculations are quite complex (different charge rates,
>time periods e.g std and overtime etc) I thought that once calculated (at
>the point of data entry) why not store these values in table (may improved
>report speed/programming). Alternativley, isn't this what computers are for
>ie carrying out complex calculations so why store value, when it comes to
>reporting on or
>displaying etc simply recaculate.   My leaning now is not to store these
>values. Any thoughts?
>
>Richard
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada