On 7 October 2011 06:33, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>
> Glad to be of help!
>
> There is often a tradeoff between flexibility and performance.
>
> What you tried to do looks pretty neat.
>
> Would writing something in C give you sufficient flexibility with reasonable
> performance?
Possibly, but I wouldn't know where to start. I just did some more
testing, and the most performant solution is to just have both columns
(fraction and amount) default them to 1 and 0 respectively, then just
calculate (price * fraction + amount).
> However, in a production system, and in an environment where most people do
> not have a range of skills in depth, it is better to keep things simple - to
> ease ongoing maintenance. Sometimes super smart code is a liability, as
> mere mortals can not maintain it. I have been guilty of this crime!
>
> I guess a good rule of thumb, is imagine that you are called back in 2 years
> to fix, or modify your code - how would you feel: still proud of what you
> did, or wonder what you were thinking at the time (or both!)?
>
> Somes a bit of complexity is necessar, and can save a lot of code, or imply
> be the most practical way of doing something.
I was trying to build some flexibility in so that I wouldn't need to
revisit this in the future :) Down the track, I'll investigate
operator/function lookups further, but I'll keep it simple for the
time being.
BTW, is novice the right list for questions like these?
> Note that one of the points I was trying to make is to avoid float type data
> types for money. In COBOL we used integers to hold the number of cents, so
> add&subtract operations were not subject to rounding, in pg you can use the
> money type.
Thanks for the tip, this is mostly an analysis database, so rounding
won't be an issue.
Cheers,
Tony