在 MySQL 数据库中存储货币值的最佳数据类型

Question

货币值的最佳 SQL 数据类型是什么？我正在使用 MySQL，但更喜欢独立于数据库的类型。

原文由 Brian Fisher 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

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

原文由 Kibbee 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

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

我的情况

• 用于记录货币交易的小数（13,4）无符号
  • 存储效率（小数点每侧 4 个字节） 1
  • 符合公认会计原则
• 十进制（19,4）无符号聚合
  • 我们需要更多空间来处理数十亿笔交易
  • 半遵从 MS Currency 数据类型不会受到伤害 2
  • 每条记录将占用更多空间（11 字节 - 7 左和 4 右），但这很好，因为聚合 1 的记录较少
• 十进制（10,5）汇率
  • 它们通常用 5 位数字引用，因此您可以找到像 1.2345 & 12.345 但不是 12345.67890 这样的值
  • 这是普遍的惯例，但不是编纂的标准（至少根据我的快速搜索知识）
  • 您可以使用相同的存储将其设为十进制 (18,9)，但数据类型限制是有价值的内置验证机制

为什么是（M，4）？

• 有一种货币可以分裂成一千便士
• 有像“Unidad de Fermento”、“CLF”这样的货币等价物，用 4 个有效小数位表示 3 , 4
• 它符合公认会计原则

权衡

• 较低的精度：
  • 存储成本更低
  • 更快的计算
  • 降低计算错误风险
  • 更快的备份和恢复
• 更高的精度：
  • 未来的兼容性（数字趋于增长）
  • 节省开发时间（当达到限制时，您不必重建半个系统）
  • 由于存储精度不足而降低生产失败的风险

兼容极限

虽然 MySQL 允许您使用小数（65,30），但如果我们想让传输选项保持打开状态，31 表示比例和 30 表示精度似乎是我们的限制。

最常见 RDBMS 中的最大比例和精度：

            精密秤
甲骨文 31 31
T-SQL 38 38
MySQL 65 30
PostgreSQL 131072 16383

6、7、8、9 _ _ _

合理的极端

1. 为什么是 (27,4)？
   • 你永远不知道系统何时需要存储津巴布韦元

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

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

假设您需要以津巴布韦元记录 100 万美元的交易（今天可能不太可能，但谁知道这在 10 年后会是什么样子？）。

1. (100 万美元) * (35 Quadrylion ZWL) = ( 10^6 ) * (35 * 10^15) = 35 * 10^21
2. 我们需要：
   • 2位数字存储“35”
   • 21位存储零
   • 小数点右边4位
3. 这使得 decimal(27,4) 每个条目花费我们 15 个字节
4. 我们可以免费在左边添加一位数字 - 我们有 15 个字节的小数（28,4）
5. 现在我们可以存储以津巴布韦元表示的 1000 万美元交易，或者避免再次出现过度通胀，希望这种情况不会发生

原文由 kshishkin 发布，翻译遵循 CC BY-SA 3.0 许可协议