金额的存储用 long 可以吗

[wisetc]

想将金额的数值乘以 1000 然后再存库，方便数据的存储。让前端提交给后端的数据都先乘以 1000，然后后端返回给前端的金额数据是放大了 1000 倍的，显示的时候再让前端处理，除以 1000，后台不用对金额做任何处理，哈哈哈。我真是越来越佩服我自己。
各位后端大佬，怎么看。

[brust]

@txwd
这边有 5 位的
还是 varchar

[luozic]

小數直接切了？

[wisetc]

因为有时候金额既有用户输入又有后台代入，并不十分确定金额的来向是用户输入，用户输入的情形用来显示显然不需要做放大，然后混合系统来的数据就可能会出现问题，而且金额放大 1000 倍直观上感受并不能判断是放大后的结果（例如 1000，看不出是 1 元还是 1000 元），出现不确定性。于是，前端提倡，在前端运行中的过程量都是直接的真实数据，不希望做任何的特殊处理，对请求的后台接口封装做请求参数和返回数据的处理，但是有时候涉及到遍历，和特殊处理，这又是常见的一般性问题了，金额的字段名也不固定而且有时不必需，这显然却是一种运算力的浪费。

[tailf]

用 decimal，没有对账风险

[allanzhuo]

我司有个十几年的所谓架构师也是这样设计的，最后他滚蛋了，哈哈哈

[wlfeng]

和钱有关的数据老老实实用 decimal，不要搞事情，不然出问题了你哭都来不及

[wupher]

可以

如果计算量很多很大，使用 long 会比使用 Big Decimal 效率高很多。更别提 Big Decimal 的进位策略。

但是，使用 long 也要评估是否会碰到溢出。尤其是大规模统计的情况下。

[CantSee]

decimal 啊,这玩意跟数据库同步,多方便

[jzmws]

我第一反应为什么不用 decimal 货币型 ,最不济的用 bigint 按分来存

[SayNight]

如果业务场景金额只有加减，且判断以后绝对不会有复杂运算，因为是扩大倍数存储，要考虑 long 型溢出问题。

建议 BigDecimal，前面有 V 友提到银行用的是这个。曾在支付公司待过几年，每天流水十来亿，只允许使用：BigDecimal。不然很容易搞出事。

[sivacohan]

看你常见，如果是简单的购买行为，那你的方法是可以的。
如果是金融系统，一般做法是 Decimal 保留 4 到 6 位小数，然后定期核查，检查因为精度问题造成的损失。
最常见的常见就是 100 块钱三个人平分，最后总会有一个人多分到一分钱。

[jzmws]

@keepeye 最好做个四舍六入的 要不然到最后帐不平 .

[yalin]

听说平安一钱包大佬用这个库： https://github.com/JodaOrg/joda-money

[msg7086]

如果你是无关紧要的金融服务，比如开 VPS 收个钱什么的，那存个千分之一元也就算了。
如果是以金融为核心的服务，当然直接开大数运算咯，Decimal 或者金融专用小数格式直接用就是了。

[fairyto2]

@22too 而且也只能从 String 初始化

[thet]

我是直接用的 decimal

[lzj307077687]

反正我认为我的项目 decimal 是够用的

[li24361]

@9151 还有可能 p2p

[ZiLong]

Bigdecimal 挺好,就是那个效率是真真的慢

[VANHOR]

用整型，存分就可以。