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

什么是货币值的最佳SQL数据types? 我使用的是MySQL,但更喜欢独立于数据库的types。

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

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

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

     DBASE:10,5(10个整数,5个十进制)
     MYSQL:15,5(15位,10整数(15-5),5位十进制)

计算出您的计算可能需要多less个小数位数也是很重要的。

我工作的股票价格申请,需要计算100万股的价格。 所报的股价必须存储到7位数的准确性。

阿萨夫的回应

取决于你有多less钱…

听起来很轻浮,但实际上它是相关的。

直到今天,我们还有一个问题是logging未能插入到我们的费率表中,因为其中一列(GrossRate)被设置为十进制(11,4),而我们的产品部门刚刚得到了一些令人惊叹的房间的合同在波拉波拉岛,每晚售出几百万太平洋法郎……当数据库架构是在10年前devise时,从来没有反对过。

对于会计应用程序来说,将值存储为整数是非常常见的(有些甚至可以说是唯一的方法)。 为了得到一个想法,把交易金额(假设为100.23美元)和倍数100,1000,10000等,以获得您所需要的准确性。 所以如果你只需要存储美分,并且可以安全地向上或向下舍入,就乘以100.在我的例子中,这将使得10023作为整数来存储。 您将节省数据库中的空间,比较两个整数要比比较两个浮点数容易得多。 我的$ 0.02。

超级晚入场但GAAP是一个很好的经验法则。

如果您的应用程序需要处理高达一万亿的货币价值,那么这应该起作用:13,2如果您需要遵守GAAP(通用会计准则),则使用:13,4

通常你应该把你的货币价值总和为13,4,然后把产出四舍五入到13,2。

来源: 在MySQL中存储货币值的最佳数据types

对于所有的货币值,您可以默认使用DECIMAL(19,2)类的东西,但是如果您只存储低于$ 1,000的值,那将浪费宝贵的数据库空间。

对于大多数实现, DECIMAL(N,2)就足够了,其中N的值至less是前面的位数. 这是你所期望存在的最大的总和+ 5 。 所以如果你不希望存储任何大于999999.99的值,那么DECIMAL(11,2)应该是DECIMAL(11,2) (直到期望值改变)。

如果你想要符合GAAP标准,你可以使用DECIMAL(N,4) ,其中N的值至less是前面的位数. 这是你所期望存在的最大的总和+7。

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

我的情况

  • 十进制(13,4)未签名以logging货币交易
    • 存储效率高(反正小数点每边4字节) 1
    • 符合GAAP标准
  • 十进制(19,4)无符号聚合
    • 我们需要更多的空间来处理数十亿多笔交易
    • 符合MS货币数据types不会受到伤害2
    • 每个logging需要更多的空间(11个字节–7个左边和4个右边),但这没有问题,因为聚合1的logging较less
  • 十进制(10,5)为汇率
    • 他们通常引用5位数字,所以你可以find像1.2345和12.345,但不是12345.67890
    • 这是广泛的惯例,但不是一个编纂的标准(至less对我的快速search知识)
    • 你可以用相同的存储使它成为十进制(18,9),但数据types限制是有价值的内置validation机制

为什么(M,4)?

  • 有货币分成千便士
  • 还有一些相当于“Unidad de Fermento”,“CLF”等4个小数位的数字3,4
  • 它符合GAAP标准

交易

  • 精度较低:
    • 更less的存储成本
    • 更快的计算
    • 降低计算错误风险
    • 更快的备份和恢复
  • 更高的精度:
    • 未来的兼容性(数字往往会增长)
    • 节省开发时间(在满足限制时,您不必重build一半系统)
    • 由于储存精度不足导致生产失败的风险降低

兼容极端

尽pipeMySQL让你使用十进制(65,30),但是如果我们想要让转换选项打开的话,31的比例和30的精度似乎是我们的极限。

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

            精确度量表
 Oracle 31 31
 T-SQL 38 38
 MySQL 65 30
 PostgreSQL 131072 16383

6,7,8,9

合理的极端

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

津巴布韦政府表示将以1美元兑换津巴布韦元兑换35美元津巴布韦元5美元

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

假设您需要以津巴布韦元纪录一笔100万美元的交易(今天可能不大可能,但是谁知道10年后的情况呢?)。

  1. (100万美元)*(35 Quadrylion ZWL)=(10 ^ 6)*(35 * 10 ^ 15)= 35 * 10 ^ 21
  2. 我们需要:
    • 2位数字来存储“35”
    • 21位数字来存储零
    • 小数点右边4位数字
  3. 这使得十进制(27,4),每个条目花费我们15个字节
  4. 我们可以在左边再增加一个数字 – 我们有15个字节的十进制(28,4)
  5. 现在我们可以储存1000万美元的津巴布韦元交易,或者保证不会再发生通货膨胀,希望不会发生

虽然这可能会很晚,但是对别人有帮助。根据我的经验和研究,我已经了解并接受了十进制(19,6)。那就是在使用php和mysql的时候。 当工作与大量的金钱和汇率