您可以在默认情况下对所有货币值使用DECIMAL(19,2)之类的值，但如果您只存储低于1,000美元的值，那么这将浪费宝贵的数据库空间。

对于大多数实现，DECIMAL(N,2)就足够了，其中N的值至少是。你期望存储在这个字段中的最大的总和中+ 5。因此，如果您不希望存储任何大于999999.99的值，DECIMAL(11,2)应该绰绰有余(直到期望发生变化)。

如果您希望符合GAAP，则可以使用DECIMAL(N,4)，其中N的值至少是。在你期望存储在这个字段中的最大的总和中+ 7。

Assaf的回应

这取决于你有多少钱…

听起来很轻率，但实际上是相关的。

就在今天，我们遇到了一个问题，记录未能插入到我们的Rate表中，因为其中一列(GrossRate)被设置为Decimal(11,4)，而我们的产品部门刚刚获得了一份合同，在Bora Bora的某个令人惊讶的度假胜地，每晚售价数百万太平洋法郎……这是10年前设计数据库模式时从未预料到的。

Decimal(19,4)在大多数情况下工作得很好。您可以调整比例和精度，以适应您需要存储的数字的需要。即使在SQL Server中，我也不倾向于使用“money”，因为它是不标准的。

这取决于数据的性质。你需要事先考虑清楚。

我的情况

decimal(13,4) unsigned for recording money transactions storage efficient (4 bytes for each side of decimal point anyway) 1 GAAP compliant decimal(19,4) unsigned for aggregates we need more space for totals of multiple multi-billion transactions semi-compliance with MS Currency data type won't hurt 2 it will take more space per record (11 bytes - 7 left & 4 right), but this is fine as there are fewer records for aggregates 1 decimal(10,5) for exchange rates they are normally quoted with 5 digits altogether so you could find values like 1.2345 & 12.345 but not 12345.67890 it is widespread convention, but not a codified standard (at least to my quick search knowledge) you could make it decimal (18,9) with the same storage, but the datatype restrictions are valuable built-in validation mechanism

为什么(M, 4) ?

有些货币可以分成一千个便士 还有货币等价物，比如"Unidad de Fermento"， "CLF"用四位有效小数点后3,4表示 它符合美国公认会计准则

权衡

低精度: 存储成本低 更快的计算 降低计算错误风险 更快的备份和恢复 更高的精度: 未来兼容性(数量趋于增长) 节省开发时间(当达到限制时，您不必重新构建半个系统) 由于存储精度不够，降低生产失败的风险

兼容的极端

虽然MySQL允许您使用十进制(65,30)，但如果我们想要保留传输选项，31表示刻度，30表示精度似乎是我们的限制。

最常见RDBMS的最大规模和精度:

            Precision   Scale
Oracle      31          31
T-SQL       38          38
MySQL       65          30
PostgreSQL  131072      16383

Six, seven, eight, nine

合理的极端

为什么(27岁,4)? 你永远不知道系统什么时候需要储存津巴布韦元

2015年9月，津巴布韦政府宣布将以1美元兑换35千万亿津巴布韦元5美元的汇率兑换津巴布韦元

我们倾向于说“是的，当然……我不需要那些疯狂的数字。”津巴布韦人以前也这么说。不久以前。

让我们想象一下，你需要记录一笔100万美元的津巴布韦元交易(今天可能不太可能，但谁知道10年后会是什么样子呢?)

(100万美元)* (35 Quadrylion ZWL) = (10^6) * (35 * 10^15) = 35 * 10^21 我们需要: 2位数字存储“35” 用21位数字来存储零 小数点右4位 这就得到了十进制(27,4)，每个条目花费15个字节 我们可以免费在左边再加一位数字——我们用十进制(28,4)表示15字节 现在我们可以储存1000万美元的津巴布韦元交易，或者避免另一次高通胀的打击，希望不会发生

您可以在默认情况下对所有货币值使用DECIMAL(19,2)之类的值，但如果您只存储低于1,000美元的值，那么这将浪费宝贵的数据库空间。

对于大多数实现，DECIMAL(N,2)就足够了，其中N的值至少是。你期望存储在这个字段中的最大的总和中+ 5。因此，如果您不希望存储任何大于999999.99的值，DECIMAL(11,2)应该绰绰有余(直到期望发生变化)。

如果您希望符合GAAP，则可以使用DECIMAL(N,4)，其中N的值至少是。在你期望存储在这个字段中的最大的总和中+ 7。

虽然这可能有点晚，但对其他人来说是有帮助的。根据我的经验和研究，我已经知道并接受十进制(19,6)，这是在使用php和mysql时。当工作与大量的钱和汇率