have total fields or not 
Author Message
 have total fields or not

In a table, I have the following for a part:

mold making hr, mold maker rate
finishing hr, finisher rate
pattern prepping hr, master finisher rate...

about 3-4 other hrs and rate...

Should I have fields for the pricing for each? for example:

moldmakeprice (mold making hr * mold maker rate)
finishprice (finish hr * finish rate)
patternprepprice (patternprep hr * master finisher rate)

or should i leave it floating?  so if i ever need the rinfo, i would
have to always do finishprice = finishhr * finishrate     ?

The Pros of having permanent fields for these is that you can easily
look them up instead of using formulas.  The Con of it is that if you
are on the form and a use updates the finish rate, the price field will
have to be updated too.  Of course, you also have alot more fields in
your table.

The Pro of having it floating is that you can change the rate and hr and
the price fields will automatically update.  the con is that you have to
always use the formula to get pricing, instead of having the total amt
saved in a field.

What is better?

Down the road, I may have to use the pricing fields alot (adding them up
for a quote)

Right now, I have the permanent fields and the number of fields in the
table is 57.  If I didn't have the permanent fields, I would have 10
less fields.

Thanks.
Ngan



Fri, 29 Nov 2002 03:00:00 GMT  
 have total fields or not
Never, ever store derived data in your tables (unless you're forced to <g>).

Steve

Quote:

>In a table, I have the following for a part:

>mold making hr, mold maker rate
>finishing hr, finisher rate
>pattern prepping hr, master finisher rate...

>about 3-4 other hrs and rate...

>Should I have fields for the pricing for each? for example:

>moldmakeprice (mold making hr * mold maker rate)
>finishprice (finish hr * finish rate)
>patternprepprice (patternprep hr * master finisher rate)

>or should i leave it floating?  so if i ever need the rinfo, i would
>have to always do finishprice = finishhr * finishrate     ?

>The Pros of having permanent fields for these is that you can easily
>look them up instead of using formulas.  The Con of it is that if you
>are on the form and a use updates the finish rate, the price field will
>have to be updated too.  Of course, you also have alot more fields in
>your table.

>The Pro of having it floating is that you can change the rate and hr and
>the price fields will automatically update.  the con is that you have to
>always use the formula to get pricing, instead of having the total amt
>saved in a field.

>What is better?

>Down the road, I may have to use the pricing fields alot (adding them up
>for a quote)

>Right now, I have the permanent fields and the number of fields in the
>table is 57.  If I didn't have the permanent fields, I would have 10
>less fields.

>Thanks.
>Ngan



Fri, 29 Nov 2002 03:00:00 GMT  
 have total fields or not
so you saying dont store the totals and, when i need to access that info, just
use formulas?

Why shouldnt you store the data?  when ya say "unless you're forced to", got any
examples where ya need to?

Thanks.

Quote:

> Never, ever store derived data in your tables (unless you're forced to <g>).

> Steve

> >In a table, I have the following for a part:

> >mold making hr, mold maker rate
> >finishing hr, finisher rate
> >pattern prepping hr, master finisher rate...

> >about 3-4 other hrs and rate...

> >Should I have fields for the pricing for each? for example:

> >moldmakeprice (mold making hr * mold maker rate)
> >finishprice (finish hr * finish rate)
> >patternprepprice (patternprep hr * master finisher rate)

> >or should i leave it floating?  so if i ever need the rinfo, i would
> >have to always do finishprice = finishhr * finishrate     ?

> >The Pros of having permanent fields for these is that you can easily
> >look them up instead of using formulas.  The Con of it is that if you
> >are on the form and a use updates the finish rate, the price field will
> >have to be updated too.  Of course, you also have alot more fields in
> >your table.

> >The Pro of having it floating is that you can change the rate and hr and
> >the price fields will automatically update.  the con is that you have to
> >always use the formula to get pricing, instead of having the total amt
> >saved in a field.

> >What is better?

> >Down the road, I may have to use the pricing fields alot (adding them up
> >for a quote)

> >Right now, I have the permanent fields and the number of fields in the
> >table is 57.  If I didn't have the permanent fields, I would have 10
> >less fields.

> >Thanks.
> >Ngan



Fri, 29 Nov 2002 03:00:00 GMT  
 have total fields or not
oh...what of this reason for having it:
A user wants to manually enter in a price?
these totals could also expand to the unit price and extended price.  So if a
user wants to by pass doing the hrs and rate (or if the part doesn't have hrs or
rates), he can just enter in the unit price.
Quote:

> Never, ever store derived data in your tables (unless you're forced to <g>).

> Steve

> >In a table, I have the following for a part:

> >mold making hr, mold maker rate
> >finishing hr, finisher rate
> >pattern prepping hr, master finisher rate...

> >about 3-4 other hrs and rate...

> >Should I have fields for the pricing for each? for example:

> >moldmakeprice (mold making hr * mold maker rate)
> >finishprice (finish hr * finish rate)
> >patternprepprice (patternprep hr * master finisher rate)

> >or should i leave it floating?  so if i ever need the rinfo, i would
> >have to always do finishprice = finishhr * finishrate     ?

> >The Pros of having permanent fields for these is that you can easily
> >look them up instead of using formulas.  The Con of it is that if you
> >are on the form and a use updates the finish rate, the price field will
> >have to be updated too.  Of course, you also have alot more fields in
> >your table.

> >The Pro of having it floating is that you can change the rate and hr and
> >the price fields will automatically update.  the con is that you have to
> >always use the formula to get pricing, instead of having the total amt
> >saved in a field.

> >What is better?

> >Down the road, I may have to use the pricing fields alot (adding them up
> >for a quote)

> >Right now, I have the permanent fields and the number of fields in the
> >table is 57.  If I didn't have the permanent fields, I would have 10
> >less fields.

> >Thanks.
> >Ngan



Fri, 29 Nov 2002 03:00:00 GMT  
 have total fields or not
Ngan,

Quote:
>>>oh...what of this reason for having it:

I stand by my statement against storing derived data and believe it creates
a relational nightmare.

The reasons are many:
- you'll need to constantly maintain this derived data every time one of the
components of each and every row change
- if you're storing data which can be easily calculated
- it's a waste of storage space

You may have to change the database design if one or more of the fields is
not known.

I suggest moving this conversation to the *.access.tabledbdesign forum since
it's a bit off topic for programming...

Steve

Steve

Quote:

>oh...what of this reason for having it:
>A user wants to manually enter in a price?
>these totals could also expand to the unit price and extended price.  So if
a
>user wants to by pass doing the hrs and rate (or if the part doesn't have
hrs or
>rates), he can just enter in the unit price.


>> Never, ever store derived data in your tables (unless you're forced to
<g>).

>> Steve

>> >In a table, I have the following for a part:

>> >mold making hr, mold maker rate
>> >finishing hr, finisher rate
>> >pattern prepping hr, master finisher rate...

>> >about 3-4 other hrs and rate...

>> >Should I have fields for the pricing for each? for example:

>> >moldmakeprice (mold making hr * mold maker rate)
>> >finishprice (finish hr * finish rate)
>> >patternprepprice (patternprep hr * master finisher rate)

>> >or should i leave it floating?  so if i ever need the rinfo, i would
>> >have to always do finishprice = finishhr * finishrate     ?

>> >The Pros of having permanent fields for these is that you can easily
>> >look them up instead of using formulas.  The Con of it is that if you
>> >are on the form and a use updates the finish rate, the price field will
>> >have to be updated too.  Of course, you also have alot more fields in
>> >your table.

>> >The Pro of having it floating is that you can change the rate and hr and
>> >the price fields will automatically update.  the con is that you have to
>> >always use the formula to get pricing, instead of having the total amt
>> >saved in a field.

>> >What is better?

>> >Down the road, I may have to use the pricing fields alot (adding them up
>> >for a quote)

>> >Right now, I have the permanent fields and the number of fields in the
>> >table is 57.  If I didn't have the permanent fields, I would have 10
>> >less fields.

>> >Thanks.
>> >Ngan



Sat, 30 Nov 2002 03:00:00 GMT  
 have total fields or not

Quote:

>so you saying dont store the totals and, when i need to access that info,
just
>use formulas?

Exactly.

Quote:
>Why shouldnt you store the data?  when ya say "unless you're forced to",
got any
>examples where ya need to?

Please see my other reply for reasons not to store derived data. I can't
think of any reasons (really) where I have had to store derived data with
the base table data. There are certainly times where it is necessary, mostly
for reporting reasons to temporarily store derived data in tables separate
from the base data. Since this is calculated data it can be easily replaced
or recalculated as needed.

Steve

Quote:

>> Never, ever store derived data in your tables (unless you're forced to
<g>).

>> Steve

>> >In a table, I have the following for a part:

>> >mold making hr, mold maker rate
>> >finishing hr, finisher rate
>> >pattern prepping hr, master finisher rate...

>> >about 3-4 other hrs and rate...

>> >Should I have fields for the pricing for each? for example:

>> >moldmakeprice (mold making hr * mold maker rate)
>> >finishprice (finish hr * finish rate)
>> >patternprepprice (patternprep hr * master finisher rate)

>> >or should i leave it floating?  so if i ever need the rinfo, i would
>> >have to always do finishprice = finishhr * finishrate     ?

>> >The Pros of having permanent fields for these is that you can easily
>> >look them up instead of using formulas.  The Con of it is that if you
>> >are on the form and a use updates the finish rate, the price field will
>> >have to be updated too.  Of course, you also have alot more fields in
>> >your table.

>> >The Pro of having it floating is that you can change the rate and hr and
>> >the price fields will automatically update.  the con is that you have to
>> >always use the formula to get pricing, instead of having the total amt
>> >saved in a field.

>> >What is better?

>> >Down the road, I may have to use the pricing fields alot (adding them up
>> >for a quote)

>> >Right now, I have the permanent fields and the number of fields in the
>> >table is 57.  If I didn't have the permanent fields, I would have 10
>> >less fields.

>> >Thanks.
>> >Ngan



Sat, 30 Nov 2002 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Adding different sorted totals into a grand total field

2. Having trouble accessing single field key with two concatenated fields

3. Total field will not automctically total when tab order macro is active?

4. Having problems with sorting character or text fields

5. Totaling Values in a Field

6. Running Totals in unbound field

7. Having trouble getting the Alias (Account) field data from a global address

8. Total Slack field

9. Powerpoint - total pages field

10. Form field to calculate total

11. Help: having trouble with IF statements and calculated fields

12. Problem: Total fields in Crystal Reports

 

 
Powered by phpBB® Forum Software