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

时间：2009-03-10 01:36:23

标签： mysql sql sqldatatypes

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

9 个答案:

答案 0 :(得分：223)

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

答案 1 :(得分：47)

您唯一需要注意的是，如果您从一个数据库迁移到另一个数据库，您可能会发现DECIMAL（19,4）和DECIMAL（19,4）意味着不同的东西

（http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html）

    DBASE: 10,5 (10 integer, 5 decimal)
    MYSQL: 15,5 (15 digits, 10 integer (15-5), 5 decimal)

答案 2 :(得分：17)

Assaf对

的回应
  

取决于你得到多少钱......

听起来很轻浮，但实际上它是有针对性的。

仅在今天我们遇到了一个问题，即记录未能插入到我们的费率表中，因为其中一列（GrossRate）设置为十进制（11,4），而我们的产品部门刚收到一个房间合同波拉波拉岛上一些令人惊叹的度假胜地，每晚售价数百万太平洋法郎...... 10年前设计数据库架构时从未反映过的东西。

答案 3 :(得分：17)

计算出计算所需的小数位数也很重要。

我参与了一项股价申请，要求计算一百万股的价格。报价的股票价格必须保存为7位精确度。

答案 4 :(得分：10)

对于会计应用程序，将值存储为整数是非常常见的（有些甚至可以说它只是 方式）。要了解一下，请考虑交易金额（假设为100.23美元）和100,1000,10000等倍数，以获得所需的准确性。因此，如果您只需要存储美分并且可以安全地向上或向下舍入，则只需乘以100.在我的示例中，这将使10023成为要存储的整数。您将节省数据库中的空间，并且比比较两个整数 比比较两个浮点数更容易。我的0.02美元。

答案 5 :(得分：8)

超级迟到，但GAAP是一个很好的经验法则。

如果您的申请需要处理高达万亿的金额，那么这应该有效：13,2如果您需要遵守GAAP（公认会计原则），请使用：13,4

通常你应该把你的货币价值加在13,4，然后再将产出四舍五入到13,2。

来源：Best datatype to store monetary value in MySQL

答案 6 :(得分：5)

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

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

如果您希望符合GAAP，则可以使用DECIMAL(N,4)，其中N的值至少是.之前的数字{}您希望存储在该字段+ 7中的最大金额。

答案 7 :(得分：3)

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

我的案例

  • 十进制（13,4）未签名用于记录货币交易
    • 存储有效（无论如何，小数点每边4个字节）1
    • 符合GAAP标准
  • 十进制（19,4）未签名的聚合
    • 我们需要更多空间来处理多个数十亿交易的总数
    • 半合规MS货币数据类型不会伤害2
    • 每个记录需要更多的空间（11个字节 - 左7个和右4个），但这很好，因为聚合的记录较少1
  • 十进制（10,5）汇率
    • 它们通常被引用5个数字，所以你可以找到像1.2345＆amp; 12.345但不是12345.67890
    • 这是一个普遍的惯例，但不是一个编纂的标准（至少对我的快速搜索知识而言）
    • 你可以使用相同的存储使其成为十进制（18,9），但数据类型限制是有价值的内置验证机制

为什么（M，4）？

  • 有些货币分成千元便士
  • 有钱等同于＆＃34; Unidad de Fermento＆＃34;，＆＃34; CLF＆＃34;用4位有效小数点3，4
    • 表示
  • 符合GAAP标准

权衡

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

兼容极端

虽然MySQL允许你使用十进制（65,30），如果我们想让传输选项保持打开状态，那么31为缩放，30为精度似乎是我们的限制。

最常见的RDBMS中的最大规模和精度：

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

6，7，8，9

合理的极端

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

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

    我们倾向于说＆＃34;是的，当然......我不会需要那些疯狂的数字＆＃34;。那么，津巴布韦人也常说。不久前。

    让我们想象你需要用津巴布韦元记录100万美元的交易（今天可能不太可能，但是谁知道从现在开始10年后这会是怎样的？）。

      
        
    1. （1百万美元）*（35 Quadrylion ZWL）=（10 ^ 6）*（35 * 10 ^ 15）= 35 * 10 ^ 21
      2.   
    2. 我们需要：      
          
      • 要存储的2位数＆＃34; 35＆＃34;
        •   
      • 存储零的21位数字
        •   
      • 小数点右侧4位数
        •   
      3.   
    3. 这使得十进制（27,4）每个条目花费我们15个字节
      4.   
    4. 我们可以在左边免费添加一个数字 - 我们有15个字节的十进制（28,4）
      5.   
    5. 现在我们可以存储以津巴布韦元表示的1000万美元的交易，或者从另一次的hiperinflation罢工中获得保障，这有希望不会发生
      6.   

答案 8 :(得分：0)

虽然这可能会迟到，但它会对其他人有所帮助。从我的经验和研究中我已经知道并接受十进制（19,6）。那就是使用php和mysql时。在处理大量资金和汇率时

相关问题
最新问题