【SQL】金额如果存在数据库中应该使用何种类型?

发布网友发布时间：2022-04-24 03:12

共6个回答

热心网友时间：2022-04-09 11:48

在工作中发现原本系统中金额类型（int 10，存入数据库时乘100）已经不能满足当前需求，需要重新修改类型。于是像技术总监发起两次审批，但都被驳回了。第一次金额类型为 DECIMAL(32,8) , 第二次类型是 DECIMAL(10,2），之后技术总监说，你第一次的类型可能是对的，于是小彭百思不得其解，引发以下的灵魂三问......

为什么系统期初设置金额时要用 int 10 类型？
为什么两次审批都被驳回？
为什么后来技术总监又说第一次的可能是对的？
简单思考过后：小彭，大胆的推测了第一个问题，可能是当初设计数据结构时，认为金额精确到分即可，所以默认乘100 （保留两位小数）。但金额最大为 9千万元，是否真的能符合要求，回头还得再问问技术总监。这时，小彭又想到两个问题：

既然是保留小数了，为什么还要用 INT 类型呢？
如果说 FLOAT和 DOUBLE类型可能会存在精度问题，又为什么不用 DECIMAL类型呢？
经过查阅博客之后：小大概想通了第二个问题，第一次被驳回的原因是：DECIMAL类型在数据库中是根据传入的数值来决定存储的字节长度的，32明显过长会导致磁盘空间的浪费。而第二次则是走了另外一个极端：原本长度为10已经快要满足不了需求的了，如果再修改为同样的长度意义不大，还会引起后续再次修改类型的情况。

又结合系统反思了一下：大概明白了第三个问题，至于金额的长度其实是没有没有一个具体的标准的，要根据具体业务情况，预估最大的金额上限，再决定具体长度。

意料之外的惊喜，在看书籍中意外的解决了第二组的两个问题。由于CPU不支持对 DECIMAL 的直接计算，所以在计算的过程中需要额外的空间及计算开销，导致性能过慢。还存在另外一种解决方案：使用 BIGINT 代替 DECIMAL，在计算时，可以乘或除以相应的倍数即可，来取代 DECIMAL 计算代价高的问题。

最后总结：

FLOAT和 DOUBLE类型会存在精度问题，是因为十进制0.1在电脑里用二进制是无法精确表示的。
DECIMAL类型在数据库中存储的字节长度计算公式：对decimal(M,D) ，如果M>D，长度为M+2，否则为D+2。
要根据具体业务情况，预估最大的金额上限，再决定具体长度。
DECIMAL 计算的过程中需要额外的空间及计算开销，性能低。

热心网友时间：2022-04-09 13:06

一般用money或decimal或numeric,而不用float或double,因为容易出现"失真".

money货币数据存储的精确度为四位小数。可以存储在 money 数据类型中的值的范围是 -922,337,203,685,477.5808 至 +922,337,203,685,477.5807（需 8 个字节的存储空间）。

在 SQL Server中，numeric 数据类型等价于 decimal 数据类型。存储 decimal 或 numeric 数值所需的字节数取决于该数据的数字总数和小数点右边的小数位数。

热心网友时间：2022-04-09 14:40

一般用money或decimal或numeric,而不用float或double,因为容易出现"失真".
money货币数据存储的精确度为四位小数。可以存储在 money 数据类型中的值的范围是 -922,337,203,685,477.5808 至 +922,337,203,685,477.5807（需 8 个字节的存储空间）。
在 SQL Server中，numeric 数据类型等价于 decimal 数据类型。存储 decimal 或 numeric 数值所需的字节数取决于该数据的数字总数和小数点右边的小数位数。

热心网友时间：2022-04-09 16:32

int varchar 都可以输出时做个格式化