好的,所以我知道有很多文章说明我不应该使用DOUBLE在MySQL数据库上存储资金,否则我将遇到棘手的精度错误。关键是我不是在设计新数据库,而是在寻找一种方法来优化现有系统。较新的版本包含783个DOUBLE类型的列,其中大多数用于存储金额或用于计算金额的公式。
因此,我对此主题的第一意见是,我强烈建议在下一个版本中将DOUBLE转换为DECIMAL,因为MySQL文档和所有人都这么说。但是由于以下三个原因,我找不到合适的论据来证明这一建议:
我们不对数据库执行任何计算。所有操作都使用BigDecimal在Java中完成,而MySQL仅用作结果的普通存储。 DOUBLE提供的15位精度足够了,因为我们存储的金额主要是2个小数位,对于公式参数,偶尔会存储8个小数位的数字。 我们已经有6年的生产记录,并且由于MySQL方面的精度损失而没有已知的错误问题。 即使通过对18毫米行表执行运算(例如SUM和复杂的乘法),我也无法执行缺乏精度的错误。而且我们实际上并没有在生产中做这种事情。我可以通过执行类似的操作来显示丢失的精度
SELECT columnName * 1.000000000000000 FROM tableName;
但是我想不出一种方法来将它转换为错误的小数点后两位数字。我在互联网上发现的大多数实际问题是2005年和更早的论坛条目,我无法在5.0.51 MySQL服务器上重现它们中的任何一个。
因此,只要我们不执行我们不打算执行的任何SQL算术运算,那么仅在DOUBLE列中存储和取回金额是否会有任何问题吗?
其实是完全不同的。DOUBLE会导致舍入问题。如果你做这样的事,0.1 + 0.2它就会给你一些像0.30000000000000004。我个人不相信使用浮点数学的财务数据。影响可能很小,但谁知道呢。我宁愿拥有我所知道的可靠数据,也不愿获得近似数据,尤其是在处理货币价值时。来源:stack overflow
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。