类似的东西 Decimal(19,4) 通常在大多数情况下都能很好地工作。您可以根据需要存储的数字的需要调整比例和精度。即使在SQL Server中,我也不会使用“ money “因为这是不标准的。

唯一需要注意的是,如果您从一个数据库迁移到另一个数据库,您可能会发现十进制(19,4)和十进制(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)

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

我做过一个股票价格申请,需要计算一百万股的价格。所报股价必须精确到7位数。

阿萨夫的回应

取决于你有多少钱…

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

就在今天,我们遇到了一个问题,因为其中一列(格罗斯拉特)被设置为十进制(11,4),而我们的产品部门刚刚得到了一份合同,在波拉波拉的某个令人惊异的度假胜地的房间,每晚卖出数百万太平洋法郎……这是10年前设计数据库模式时从未预料到的。

对于会计应用程序来说,将值存储为整数是很常见的(有些甚至可以说是 只有 方法)为了得到一个想法,取交易量(假设100.23美元)乘以100、1000、10000等,得到所需的准确度。所以,如果你只需要存储美分,并且可以安全地上下取整,只需乘以100。在我的示例中,这将使10023成为要存储的整数。您将在数据库中节省空间并比较两个整数 许多的 比比较两个浮点数更容易。我的0.02美元。

超级晚入学,但公认会计准则是一个很好的经验法则。

如果您的应用程序需要处理高达1万亿的货币价值,那么这应该是有效的:13,2如果您需要遵守GAAP(公认会计原则),那么使用:13,4

通常,在将输出四舍五入到13,2之前,您应该将您的货币值总和为13,4。

来源: Best datatype to store monetary value in MySQL

你可以用类似的东西 DECIMAL(19,2) 默认情况下,对于所有的货币价值,如果您只存储低于1000美元的价值,那将是浪费宝贵的数据库空间。

对于大多数实现, DECIMAL(N,2) 如果 N 至少是 . 这是你所期望的存储在这个领域的最大数目 + 5 . 因此,如果您不希望存储任何大于999999.99的值, DECIMAL(11,2) 应该足够(直到期望改变)。

如果你想成为 GAAP 顺从,你可以 DECIMAL(N,4) ,其中 n 至少是 . 这是你所期望的存储在这个领域的最大数目 + 7 .

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

我的案子

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

为什么(m,4)?

• 有分成一千个便士的货币
• 有一些货币等价物,如“工发组织发酵”、“CLF”,用4位小数表示。 3 , 4
• 符合GAAP标准

折衷

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

相容极限

尽管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

合理极端

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

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

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

假设您需要记录100万美元津巴布韦元的交易(今天可能不太可能,但谁知道10年后会是什么样子?).

1. (100万美元)*(35 Quadrilion 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时。在处理大量货币和汇率时