There is a common practice to store prices in integer cents to avoid a bunch of rounding errors etc. But that usually assumes that all prices require only 2 decimal places.
Are there any other approaches that eliminate rounding errors yet allow flexible decimal places?
@cwhite A hundred million flies likes to eat shit, does that make shit taste good to you?
The only time it makes sense to store a numeric value as a string, is when it has leading zeroes, that needs to be preserved, like serial numbers and model numbers. If the value you are storing is going to be used in any type of calculation it should be stored as a number, otherwise you will waste cpu cycles on converting it every time.
@Tray2 while it might be overengineering now, i think dealing with it now paves the way fully for anything that might come. In looking into brick/money, I see that several currencies use 3 decimals by default and when it comes to bitcoins etc, that is even more "uncertain".
I have more or less finished incorporating brick/money into my project already.
There is another package https://github.com/brick/money and coincided with a recent Laravel Daily video to use it as a Laravel Value Object, further more, it is able to mix 2 and 3 decimals currencies.
I plan to store currency as an integer, the only downside being, brick/money doesn't seem to have a way to add on new currencies (e.g. bitcoins etc) as a integer easily