支付相关存储金额的数据库字段，用整型还是 Decimal?

金额用整型存储分比较好，显示金额转化为元即可，传输、存储最好都用整型分。

肯定用整型，没的讨论的，结贴

别用 Decimal，decimal 读到业务层还是 float，各种分账转换后还是出问题；金额永远是 int，业务层最后展示再转成元。

什么数据库？整型是多长？

这俩本身没有什么实质差别。用 Decimal 更方便一些。

@l00t
postgresql，现在很多语言也有 Decimal 类型，但是都说用整型，了解一下有没有用 Decimal 类型的

一般精确到分足够用了吧，直接乘以 100 存整形

用户端精确到分够了，但是涉及到分佣，1 分钱乘个 3% 啥的，怎么也得小数点后 5 6 位。除非合同规则里面写明精确到分，四舍五入。

我们系统直接用了 Decimal，但是这样要求所有地方的代码也得都用 Decimal

用 Decimal,代码也用 Decimal 就行
用整型拆分的多此一举,没 Decimal 的时候没办法,有 Decimal 还这么做就跟不上时代了

只要不用浮点，都行。

当然，在没有最终性能优化需要的情况下，数据库请尽量用可读性好的数据，带少量小数位的数值就用 Decimal/Number/Numeric 类型，日期时间就用 Date/DateTime 类型。不过如果你对应的编程语言没有十进制对应的类型，那么就像前 3 楼那样用替代类型（金额放大成整数，时间用时间戳，日期用整数）好了。

一般来说，金额是必定用十进制类型的，除了不用转换外，在精度控制和四舍五入上也很方便。

@dzmcs #5 那至少得 bigint 了。单 int 是不够用的。也可以考虑用 decimal 或者 numeric，这俩本身也是同一回事。帐配不平的事情是不存在的，不用多虑。帐要是不平，肯定是你们程序自己出了问题，而不是 decimal 的数据类型问题。

记得 c#有 decimal 类型。以前用 double 老是算错，换了 decimal 就没问题了。

整型处理简单不容易出错

帐不平那是程序逻辑的问题吧, 这里多了一分肯定是另外一个地方要扣一分啊

那问题来了，日期你们用整型还是 datetime

整型，存分

财务系统，用的 decimal。 存储多几位而已

@IMCA1024 小数点后，多存几位

我们的系统数据库钱和库存都是用 decimal，代码里是 java，用 bigdecimal

金额强烈建议用 int，之前有个项目觉得用 decimal 好像也没问题，但是实际当金额进行折扣计算，还是会出现四舍五入的问题。单单为了这个增加了不知道多少的工作量

科蓝用 Decimal

@ytmsdy java 吗？要选对方法吧，不然丢精度。下面两个是正确的
BigDecimal.valueOf(double) 不信试试 new BigDecimal(0.1D)
new BigDecimal(float.toString()); 不信试试 new BigDecimal(0.1F) 或者 BigDecimal.valueOf(0.1F)