Subject | Re: [ib-support] calculated fields |
---|---|
Author | Ulrich |
Post date | 2003-04-20T18:04:37Z |
Alan,
from the actual month, to navigate in.
I noticed, that if I execute "select field1, field2, field3 ... from table"
without selecting the computed fields there is no major slow down. Am I
right, that in this case the computed fields are not calculated ?
I thought about this computed fields to gain some speed in pre-calculating
currency statistics. But thinking about it again and again, I think that I
run in a kind of "trap" cause if I "ask" for the values of these computed
fields, the server will need time to calculate them, no matter if I do it
with some computed fields or with a stored procedure which I call only if I
really need this values.
But it's allways a good idea to ask somebody else if there are different
point of views, or solutions.
By the way, I would like to ask you, if it makes sence to store a currency
value in a decimal(18,4) field definition? I allready read some mails and
articles about this topic, but I can't remember of a clear statement. Will
there be a more precise result if I do my currency calculations (statistic
calculations with some hundred currency values) with this currency field
defiition? Or will be the decimal(18,2) precise enough?
Thanks for your help.
With best regards - Ulrich
> Yes it will be calc'ed everytime you select it so a select * can becostly.
> Does your design really ever need a select * at all?you are right, normally I fill a tree with only the bills of one customer or
>
from the actual month, to navigate in.
I noticed, that if I execute "select field1, field2, field3 ... from table"
without selecting the computed fields there is no major slow down. Am I
right, that in this case the computed fields are not calculated ?
I thought about this computed fields to gain some speed in pre-calculating
currency statistics. But thinking about it again and again, I think that I
run in a kind of "trap" cause if I "ask" for the values of these computed
fields, the server will need time to calculate them, no matter if I do it
with some computed fields or with a stored procedure which I call only if I
really need this values.
But it's allways a good idea to ask somebody else if there are different
point of views, or solutions.
By the way, I would like to ask you, if it makes sence to store a currency
value in a decimal(18,4) field definition? I allready read some mails and
articles about this topic, but I can't remember of a clear statement. Will
there be a more precise result if I do my currency calculations (statistic
calculations with some hundred currency values) with this currency field
defiition? Or will be the decimal(18,2) precise enough?
Thanks for your help.
With best regards - Ulrich