double, and practically all the links of the post links.
So I realized that this was a vulnerability of my software in production (since I have
rounds for every corner before doing any kind of calculation related to monetary values). So before you have bigger problems with the clients pocket. I resolved to refactor my system using
BigDecimal for all attributes related to monetary values.
When I reached the database access layer, I came across a problem / question about how to store these values reliably and accurately in SQLite Database?
Searching I found some possibilities:
INTEGERcolumn, in the form of cents, for example:
BigDecimal valor = new BigDecimal("1.67"), in the base would be:
long valueInCents = valor.multiply(new BigDecimal(100)).longValue(), which would result in 167 in the database column, requiring the reverse process when obtaining the value of the database again. (This is what I found most effective, practical and interesting so far);
INTEGERone to the integer part of the value and another to the decimal part. (This is more comprehensive because it would give you the freedom to use as many decimal places as necessary up to the limit of% s of SQLite that I think is 18, but for monetary values maybe an unnecessary effort, if you only work with 2 pennies);
INTEGERand always convert from
String. (This would be the most practical solution since
BigDecimalhas a constructor for the value in
BigDecimal, but nevertheless it is the solution that least pleases me since it would not have the numerical value in the database, so any calculation with this column should be done via application).
- Would the column of type
String, or any other decimal variant, be accurate to store this
REALvalue while maintaining accuracy without major problems?
- Which of the three possibilities mentioned above (or some extra solution) would be more appropriate and efficient to store monetary values (with only 2 pennies)?