Re:Why SQLite succeeded as a database (2016)
by luhn on Wednesday February 19, 2020 @06:50PM
(#22371408)
Speaking from experience, if you exclusively deal with integers internally and then apply the appropriate formatting when outputting to the user (which you need to deal with regardless of internal representation), it makes dealing with monetary data so much easier. Integers are generally better supported, faster, and more convenient for most languages, databases, and serialization formats.
[ Parent
| on HN ]
Re:Why SQLite succeeded as a database (2016)
by gen220 on Wednesday February 19, 2020 @07:12PM
(#22371569)
+1 adding my anecdata to this.
If you don’t need irrational numbers (few financial applications do?), the tuple of (value, scale) can take you very far.
Re:Why SQLite succeeded as a database (2016)
by utxaa on Thursday February 20, 2020 @09:48AM
(#22375408)
you never really deal with irrationals ... do you mean floating point?
Re:Why SQLite succeeded as a database (2016)
by gen220 on Friday February 21, 2020 @10:44AM
(#22383909)
Nope, specifically meant irrationals.
Floating point (up to a certain amount of absurdity) you can describe with integers (value, scale).
Real numbers you can describe with integers (numerator, denominator, scale).
Irrationals are more difficult. That's why we try not to use them :). Hopefully your company's commission tiers are not defined in terms of circles or euclidean distances.
Re:Why SQLite succeeded as a database (2016)
by patrickthebold on Wednesday February 19, 2020 @08:50PM
(#22372092)
How do you handle things like multiplying by some interest rate of 3.125 or (1 + 0.03125)^-354 as examples.
Sure you can round at the end but then you have to worry about compounding errors.
Re:Why SQLite succeeded as a database (2016)
by anoonmoose on Wednesday February 19, 2020 @09:03PM
(#22372144)
I think that's just part of the process of deciding how small an increment each integer represents (dollars, cents, centi-cents, milli-cents).
Re:Why SQLite succeeded as a database (2016)
by elcritch on Thursday February 20, 2020 @03:51AM
(#22373689)
Accounting rules often care more about consistency than precision per se. As long as the code follows accepted accounting rules (say bankers rounding) choosing a known precision works. Often GAAP and other standards don’t define all details for, say amortization, but if you use a scheme the code should always use that method.