价格、金额设计成BigDecimal还是Long?
时间:2023年12月15日
/来源:网络
/编辑:佚名
开发时涉及金额,用什么数据类型处理
今天组长和研发总监吵起来了,
吵架原因是系统中关于价格,金额,设计成BigDecimal还是 Long 。
组长是比较有经验的开发,他觉得应该设计成BigDecimal,他之前带过很多项目都是设计成bigDecimal,从没出过问题。
总监坚持是long,说以前公司金额这块出过大问题,财务把开发骂的狗血淋头,后来改成了long就没有问题了。
以我两年半的开发经验来看,还是设计成long爽一点,计算的时候不用转换,直接干。
大家的项目中有因金额设计问题遇到的坑吗?
bigDecimal有哪些坑?long又有哪些坑?可以一起讨论下
国美电器员工评论:
存储金额,以分为单位,类型long, 我国一般情况下最小货币结算单位就是分, 特殊会用到里,豪之类的。 如果是汇算,利息要求精度比较高的时候, 存储的时候单位就得往下,
豪,微,显示的时候以元为单位,是怎么显示呢?这种分换算成元啊!
test1127算法工程师评论:
long是长整数,财务金额不支持小数点?bigdecimal虽然支持小数点,但是数额溢出就有问题了。
Java中BigDecimal类的最大值和最小值取决于BigDecimal的scale和precision属性。
徐斯远:多加一位精度位数就行了,前端展示直接插入小数点
zyxwvut评论:
用long的通常是不涉及到算利息的纯交易场景,普通交易打折可以直接抹零的。 涉及利息和收益计算的场景,不可能用long。
路漫漫其修远兮l:long单位不是存元,是直接存能结算的最小单位,甚至多预留几位,没有小数问题的。 用long也能行的,而且程序算起来方便!
后厂村少侠程序员评论:
做过三套金融系统,一套理财用BigDecimal,两套信贷用的long。如果再让我选择,我肯定用long。单位到分一般就够了,到厘的话道理是一样的,全局一致就行。很多运算变得简单不易出错,你不能指望人人都会处理好精度问题,long会避免很多麻烦,包括前后端交互也统一用long。实际上连利率都可以用long,系统设置全局精度(倍数),可以避免很多精度问题。
网络侠客新华智云员工评论:
存储用long,但是数值单元用分或者更细的精度;计算用BigDecimal,控制好过程精度。
诸葛瑾ZBoP评论:
什么年代了还讨论低端技术问题,直接问GPT4不就得了:
综合考虑,如果你们的系统需要处理大量的高精度金融计算,并且对计算的准确性有非常高的要求,那么使用BigDecimal是比较合适的。如果系统对性能要求极高,并且可以确保不会出现精度问题(例如总是以最小货币单位进行计算),则可以考虑使用Long。
在实际工作中,应该根据具体需求和团队习惯来决定。同时,也要考虑到现有系统架构和历史代码的兼容性。最好能够有详细的测试来验证所选数据类型在各种情况下的表现,确保不会因为数据类型选择错误而导致财务数据不准确。
今天组长和研发总监吵起来了,
吵架原因是系统中关于价格,金额,设计成BigDecimal还是 Long 。
组长是比较有经验的开发,他觉得应该设计成BigDecimal,他之前带过很多项目都是设计成bigDecimal,从没出过问题。
总监坚持是long,说以前公司金额这块出过大问题,财务把开发骂的狗血淋头,后来改成了long就没有问题了。
以我两年半的开发经验来看,还是设计成long爽一点,计算的时候不用转换,直接干。
大家的项目中有因金额设计问题遇到的坑吗?
bigDecimal有哪些坑?long又有哪些坑?可以一起讨论下
国美电器员工评论:
存储金额,以分为单位,类型long, 我国一般情况下最小货币结算单位就是分, 特殊会用到里,豪之类的。 如果是汇算,利息要求精度比较高的时候, 存储的时候单位就得往下,
豪,微,显示的时候以元为单位,是怎么显示呢?这种分换算成元啊!
test1127算法工程师评论:
long是长整数,财务金额不支持小数点?bigdecimal虽然支持小数点,但是数额溢出就有问题了。
Java中BigDecimal类的最大值和最小值取决于BigDecimal的scale和precision属性。
徐斯远:多加一位精度位数就行了,前端展示直接插入小数点
zyxwvut评论:
用long的通常是不涉及到算利息的纯交易场景,普通交易打折可以直接抹零的。 涉及利息和收益计算的场景,不可能用long。
路漫漫其修远兮l:long单位不是存元,是直接存能结算的最小单位,甚至多预留几位,没有小数问题的。 用long也能行的,而且程序算起来方便!
后厂村少侠程序员评论:
做过三套金融系统,一套理财用BigDecimal,两套信贷用的long。如果再让我选择,我肯定用long。单位到分一般就够了,到厘的话道理是一样的,全局一致就行。很多运算变得简单不易出错,你不能指望人人都会处理好精度问题,long会避免很多麻烦,包括前后端交互也统一用long。实际上连利率都可以用long,系统设置全局精度(倍数),可以避免很多精度问题。
网络侠客新华智云员工评论:
存储用long,但是数值单元用分或者更细的精度;计算用BigDecimal,控制好过程精度。
诸葛瑾ZBoP评论:
什么年代了还讨论低端技术问题,直接问GPT4不就得了:
综合考虑,如果你们的系统需要处理大量的高精度金融计算,并且对计算的准确性有非常高的要求,那么使用BigDecimal是比较合适的。如果系统对性能要求极高,并且可以确保不会出现精度问题(例如总是以最小货币单位进行计算),则可以考虑使用Long。
在实际工作中,应该根据具体需求和团队习惯来决定。同时,也要考虑到现有系统架构和历史代码的兼容性。最好能够有详细的测试来验证所选数据类型在各种情况下的表现,确保不会因为数据类型选择错误而导致财务数据不准确。
新闻资讯 更多
- 【建站知识】查询nginx日志状态码大于400的请求并打印整行04-03
- 【建站知识】Python中的logger和handler到底是个什么?04-03
- 【建站知识】python3拉勾网爬虫之(您操作太频繁,请稍后访问)04-03
- 【建站知识】xpath 获取meta里的keywords及description的方法04-03
- 【建站知识】python向上取整以50为界04-03
- 【建站知识】scrapy xpath遇见乱码解决04-03
- 【建站知识】scrapy爬取后中文乱码,解决word转为html 时cp1252编码问题04-03
- 【建站知识】scrapy采集—爬取中文乱码,gb2312转为utf-804-03