> At that point you are looking at full table scan to update single
> record - and it might be much worse problem then loosing one cent on
> rounding.
>
On the other hand, the application I was working on dealt with a service
model that involved tenths or hundredths of a penny per transaction, and
added up hundreds of thousands of transactions on a typical "page" of data,
so losing a penny to a rounding error would've been a very serious problem.
It really depends on the nature of the app and just how precise you need the
numbers to be.
These situations are where a properly abstracted business logic layer
comes in handy. When fully seperated from the display layer, all the
calculations take place in a single language/platform and all precisions
issues can be dealt with at one time, hopefully in a single place in the
code. Depending on the nature and purpose of the app that kind of precision
may not be required, but it still makes it a lot easier to fix precision
issues when they come up if your logic is all handled in one place.
I guess what I'm saying is it depends on the app. ;-)
ryanm
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
