[AccessD] Programming

Griffiths, Richard R.Griffiths at bury.gov.uk
Fri May 13 04:08:27 CDT 2005


Thanks Andy, Ron

I have also been thru some of the points you make.  It does seem there
can be an argument for both - I think I cam overcome changes to the
client charge rates etc by making sure if the client charge rate record
changes we archive previous (so existing records have their own record
to relate to) and create a new current charge rate record (for jobs now
and in the future).  W.r.t speed issue I think (e.g.  select records
where jobtotalhours>x ) that each client may in a year have anything
from 10-20 jobs thru to several hundred (I doubt more than 1000) in
which case this should not impact to much.

I anticipated this problem doesn't have a clear-cut yes or no answer.  I
guess as indicated I will proceed as 'don't store calculated values' and
should this have an impact on speed/reports etc I will have to revisit
and deal with accordingly.

Thanks

Richard





-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Andy Lacey
Sent: 13 May 2005 09:39
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Programming


I start by saying no in principle. Then I look for exceptional
circumstances. You mention Client Charge. To me that sounds like a Yes
because the charging algorithm may change and if it does the new
calculation should not affect previous billings. So that's one argument
for storing a calculated value. OTOH the reverse may, in many cases, be
true, i.e. that if a calculation changes existing records do want to be
affected. That would be a sound argument for not storing those
calculated values.

The other one time I go for YES is for speed. If you are likely to have
to, for example, select records where jobtotalhours>x then I'd certainly
consider storing it. At the end of the day the system's for the benefit
of a user. If you can improve the user's experience by giving him/her a
quicker answer, and the penalty isn't too great, then I'd store it. Just
make damned sure no-one can alter start or end without your program
recalculating total hours.

My 2 pen'orth Richard

--
Andy Lacey
http://www.minstersystems.co.uk



--------- Original Message --------
From: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
To: AccessD <accessd at databaseadvisors.com>
Subject: [AccessD] Programming
Date: 13/05/05 07:56

>
> 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
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com 
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
>
>
>
>

________________________________________________
Message sent using UebiMiau 2.7.2

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list