在MySQL中存储货币值的最佳数据类型
Moh*_*eri 259 mysql currency sqldatatypes
我想在MySQL数据库中存储许多记录.所有这些都包含货币价值.但我不知道每个数字会插入多少位数.
我必须为此目的使用哪种数据类型？
VARCHAR或INT(或其他数字数据类型)？
jue*_*n d 345
由于资金需要精确的表示,因此不要使用仅近似的数据类型float.您可以使用定点数字数据类型
decimal(15,2)
15是精度(包括小数位的值的总长度)2是小数点后的位数
请参阅MySQL数字类型:
在保持精确精度很重要时使用这些类型,例如使用货币数据.
- 在MySQL中,"decimal"和"numeric"是相同的. (57认同)
- 我个人使用````numeric(19,4)```作为财务记录,可以让你更好地发挥并轻松采用新的请求. (19认同)
- 我同意YahyaE,更多小数更好.有些货币通常使用3个小数位,例如巴林,约旦或科威特第纳尔,所以你需要至少3.四或五更好. (10认同)
- 在这种情况下,十进制和数字数据类型之间可能有什么区别？ (3认同)
- @EdwinHoogerbeets 不是会计师……而是在英国经营一家小型企业……我记得很久以前在某处读到过，即使对于英镑、美元等，货币数字也应存储为 4 位小数，以便某些计算可能实际上*使用*最后2个小数位用于某些模糊的会计上下文。Wd 需要会计师来确认/反驳。 (2认同)
Din*_*.R. 32
我更喜欢使用BIGINT,并将值存储乘以100,以便它将变为整数.
例如,为了表示货币值93.49,该值应存储为9349,同时显示值,我们可以除以100并显示.这将占用更少的存储空间.
注意:
大多数currency * currency情况下,我们不执行乘法,如果我们这样做,则将结果除以100并存储,以便返回到适当的精度.
- 比"DECIMAL"有什么优势？你创造了将便士转化为美元的需要,如果你在某些时候忘记它就会有祸害. (11认同)
- 如果它不明显:如果你以分数美分(例如,`$ 0.005`或`$ 0.12345`)存钱,要小心使用除垢方法,因为它们在乘以100后不会减少到整数.如果你知道精度值很明显,最好的选择是使用`DECIMAL`.但是如果你不知道精度(如我的例子中那样)那么...... FLOAT是否合适？ (4认同)
- 当使用像 JavaScript 这样使用 IEEE-754 来存储浮点数的语言时，这种方法的优势就出现了。本规范不保证 0.1 + 0.2 === 0.3 为真。将货币存储为整数可以确保您的应用程序不会发生这种错误。但这可能不是最好的解决方案。我在研究解决方案时到达了这个页面，但我还没有完成。 (2认同)
Sve*_*lav 26
这取决于你的需要.
DECIMAL(10,2)通常使用就足够了,但如果您需要更精确的值,您可以设置DECIMAL(10,4).
如果你的工作与大值替换10用19.
- @codeinprogress使用错误的语言环境/小数分隔符？ (2认同)
- @codeinprogress 您正在使用 , 进行数字分组。不要那样做。切勿使用逗号或点进行数字分组。 (2认同)
小智 15
如果您的申请需要处理高达万亿的货币价值,那么这应该有效:13,2如果您需要遵守GAAP(公认会计原则),那么使用:13,4
通常,在将输出舍入到13,2之前,您应该将您的货币值加总为13,4.
- 如果你打算拿比特币,你需要8个小数位,尽管大多数钱包都去了mBTC,这是3个http://en.wikipedia.org/wiki/Bitcoin (5认同)
在问这个问题时，没有人考虑过比特币的价格。在 BTC 的情况下，使用DECIMAL(15,2). 如果比特币升至 100,000 美元或更多，我们至少需要DECIMAL(18,9)在我们的应用程序中支持加密货币。
DECIMAL(18,9)在 MySQL 中需要 12 个字节的空间（每 9 个数字 4 个字节）。
- 我知道，但是 9 占用与 8 相同的磁盘空间。来自 MySQL 文档：“DECIMAL 列的值使用二进制格式存储，将 9 个十进制数字打包成 4 个字节” (2认同)
实际上,这取决于程序员的偏好.我个人使用:numeric(15,4)遵守公认会计原则(GAAP).
- 它与"程序员的偏好"或"你个人使用的"没有任何关系.它由问题域决定,需要十进制基数.这不是程序员可以运用自己的个人偏好的问题. (5认同)
我们使用double.
*喘气*
为什么？
因为它可以表示任何 15 位数字，而对小数点的位置没有限制。全部只有 8 个字节！
所以它可以代表：
0.123456789012345123456789012345.0
...以及介于两者之间的任何内容。
这很有用，因为我们正在处理全球货币，并且double可以存储我们可能会遇到的各种小数位数。
单个double字段可以代表日元的 999,999,999,999s，美元的 9,999,999,999,999.99s 甚至比特币的 9,999,999.99999999s
如果您尝试对 执行相同操作decimal，则需要decimal(30, 15)花费 14 个字节。
注意事项
当然，使用double并非没有警告。
然而，正如一些人倾向于指出的那样，这并不是准确性的损失。即使它double本身在内部可能不是以10 为基础的系统精确，但我们可以通过将我们从数据库中提取的值四舍五入到其有效小数位来使其精确。如果需要的话。（例如，如果要输出，则需要基数为 10 的表示。）
需要注意的是，任何时候我们用它执行算术时，我们都需要在以下之前对结果进行归一化（通过将其四舍五入到有效的小数位）：
- 对其进行比较。
- 将其写回数据库。
另一种警告是，与decimal(m, d)数据库将阻止程序插入多于m数字的数字不同，与double. 程序可以插入用户输入的 20 位数字，最终会被记录为不准确的数字。
小智 6
如果需要 GAAP 合规性或您需要 4 位小数：
DECIMAL(13, 4) 支持的最大值为：
999,999,999.9999 美元
否则，如果 2 个小数位就足够了： DECIMAL(13,2)
源代码：https : //rietta.com/blog/best-data-types-for-currencymoney-in/
BIGINT在所有“正常”情况下，以使用更少的存储空间为由存储 100 倍或更多的钱是没有意义的。
- 为了与 GAAP 保持一致，将货币存储在
DECIMAL(13,4) - MySQL手册上写着每9位数字需要4个字节来存储
DECIMAL。 DECIMAL(13,4)表示 9 位数字 + 4 位小数位（小数位）=> 4 + 2 个字节 = 6 个字节- 与存储 所需的 8 个字节相比
BIGINT。