您是否应该在SQL Server中选择MONEY或DECIMAL（x，y）数据类型？

#1 楼

绝对不要用钱。它不是精确的，它是纯垃圾。总是使用十进制/数字。 >对于某些表示您不会用金钱除以金钱的人：

这是我计算相关性的查询之一，将其更改为金钱会得出错误的结果。 br />

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

#2 楼

SQLMenace说钱不准确。但是，您不会将金钱乘以/除以金钱！ 3美元乘50美分多少钱？ 150美分？您将货币乘以/除以标量，应为小数。标量应为小数。 br /> money很好，只要您不需要超过4个十进制数字，并且您可以确保不代表金钱的标量为decimal s。

#3 楼

如果您不知道自己在做什么，一切都会很危险

即使是高精度的十进制类型也无法保存一天： > 1.000000 <-应该为0.6000000
money类型是整数可互换的。当您看到日期存储为smallmoney时，您会畏缩吗？这是同一回事。

在幕后，decimal(10,4) / varchar(10)只是money / smallmoney bigint文本表示形式中的小数点是视觉绒毛，就像yyyy-mm- dd日期。 SQL实际上并没有在内部存储这些内容。
关于int与money，请选择适合您需要的内容。之所以存在decimal类型，是因为将计费值存储为单位的1/10000的整数倍非常常见。另外，如果您要处理的是实际的金钱和计算，而不仅仅是简单的加法和减法，那么您不应该在数据库级别上这样做！使用支持Banker's Rounding（IEEE 754）的库在应用程序级别进行操作

#4 楼

我意识到WayneM曾说过他知道金钱是特定于SQL Server的。但是，他问是否有任何理由要使用十进制以上的货币，反之亦然，我认为仍然有一个明显的原因应该指出，那就是使用十进制意味着不必更改DBMS就少了一件事情-可能发生。

使您的系统尽可能灵活！

#5 楼

好吧，我喜欢MONEY！它比DECIMAL便宜一个字节，并且计算速度更快，因为（在幕后）加法和减法运算本质上是整数运算。 @SQLMenace的示例（对未意识到的用户发出的警告是个不错的警告）可以同样应用于INT egers，其结果为零。但这并没有理由在适当的地方不使用整数。

因此，当您要处理的是MONEY并根据其遵循的数学规则使用MONEY时，这绝对是“安全的”且适当的选择（与INT eger相同）。

如果可能的话，SQL Server可以将MONEY的除法和乘法提升为DECIMAL（或FLOAT？），这会更好，但是，他们没有选择做这个;在划分它们时，他们也没有选择将INT egers提升到FLOAT s。 MONEY在计算过程中使用较大的中间类型只是使用该类型的“功能”（我实际上不确定“功能”的扩展范围）。

要回答具体问题，一个“令人信服的理由”？好吧，如果您想在DECIMAL中获得绝对最大的性能，其中SUM(x)可以是x或DECIMAL，那么MONEY将具有优势。

也不要忘记它的表弟MONEY较小，仅4个字节，但确实在SMALLMONEY处达到最大值-这对于金钱来说是很小的钱，因此通常不太适合。

要证明使用较大的中间类型的意义，如果您将中间明确地分配给变量214,748.3647遇到相同的问题：

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

产生DECIMAL（好的，因此至少将2950.0000舍入而不是四舍五入到DECIMAL，与整数相同） />

#6 楼

我们刚刚遇到了一个非常相似的问题，除了顶级演示文稿之外，我现在从未使用过Money就是+1。由于历史原因，我们有多个表（实际上是一张销售凭单和一张销售发票），每个表包含一个或多个Money字段，并且我们需要执行按比例计算，以计算出与每个发票相关的总发票税额是多少行在销售凭证上。我们的计算结果是

vat proportion = total invoice vat x (voucher line value / total invoice value)

这将导致真实的货币/货币计算，这会导致划分部分的比例误差，然后乘以错误的增值税比例。随后添加这些值时，我们得出的增值税比例之和不等于发票总值。如果括号中的任何一个值都是小数点（我将这样强制转换其中一个），那么增值税比例将是正确的。我认为，由于涉及更大的价值，因此可以有效地模拟更高的规模。我们添加了括号，因为它首先进行了乘法运算，这在极少数情况下会降低计算的精度，但这现在导致了这个更常见的错误。

#7 楼

作为对其他答案总推论的对策。请参阅金钱的许多好处…数据类型！在SQLCAT的《关系引擎指南》中，

我特别指出以下内容


在处理客户实现时，我们发现了一些有趣的关于货币数据类型。例如，将
Analysis Services设置为货币数据类型（从双精度）到
与SQL Server货币数据类型匹配时，
处理速度（行/行）提高了13％。秒）。为了在SQL
服务器集成服务（SSIS）中获得更快的性能，以在30分钟之内加载1.18 TB的数据，如SSIS 2008中所述-世界纪录ETL性能，
观察到TPC-H LINEITEM表中的4个十进制（9,2）列，其大小为5
字节，转换为money（8字节），使批量
插入速度提高了20％...性能的原因改进是由于SQL Server的表格数据流（TDS）协议，该协议的主要设计原理是以紧凑的二进制形式传输数据，并尽可能接近SQL Server的内部存储格式。根据经验，这是在SSIS 2008（使用Kernrate的ETL性能世界纪录测试）中观察到的。当数据类型从十进制转换为金钱时，协议显着下降。这样可以使数据传输尽可能高效。与固定宽度类型相比，复杂的数据类型需要更多的解析和CPU周期来处理。您需要对某些算术运算更加谨慎，以保持精度，但您可能会发现，出于性能考虑，这值得。

#8 楼

我想根据我自己的专业知识和经验给出不同的货币与数值观点...我的观点是货币，因为我已经使用货币很长时间了，而且从没有真正使用数字。 。

MONEY Pro：



本地数据类型。它使用与CPU寄存器（32或64位）相同的本机数据类型（整数），因此计算不需要不必要的开销，因此它更小，更快... MONEY需要8个字节和NUMERICAL（19，4 ）需要9个字节（较大的12.5％）...多快？我对100万个数据进行了简单的SUM测试，结果显示MONEY为275毫秒，NUMERIC 517毫秒。这几乎快了一倍...为什么进行SUM测试？请参阅下一个Pro point


最佳性价比。金钱最适合用于存储金钱和进行操作，例如会计。在完成SUM操作之后，单个报告可以运行数百万个加法（SUM）和几个乘法。对于非常大的会计应用程序，它的速度几乎快一倍，而且意义非凡...

货币精度低。现实生活中的金钱并不需要非常精确。我的意思是，很多人可能会关心1美分，但是0.01美分呢？实际上，在我国，银行不再关心美分（小数点后的数字）。我不了解美国银行或其他国家/地区...

钱骗子：



有限精度。 MONEY仅具有四位数字（在逗号后）精度，因此必须在进行除法运算之前将其转换...但是，再次money并不需要那么精确，并且可以用作货币，而不仅仅是一个数字...

但是...很大，但这甚至是您的应用程序涉及到真实货币的情况，但是不要在很多SUM操作中使用它，例如在会计中。如果您使用大量除法和乘法运算，则不应使用MONEY ...

#9 楼

以前的所有文章都提出了有效的观点，但是有些文章并没有给出准确的答案。如果用于复杂的计算？

当您不进行复杂的计算时会用钱，并且可以将此精度用于其他需求。必须进行这些计算，并且需要从有效的货币文本字符串中导入数据。此自动转换仅适用于MONEY数据类型：

SELECT CONVERT(MONEY, ',000.68')

我知道您可以创建自己的导入例程。但是有时您不想使用全球特定的语言环境格式重新创建导入例程。

另一个示例，当您不必进行这些计算（您只需要存储一个值）并且需要保存1个字节（金钱占用8个字节，十进制（19,4）占用9个字节）。在某些应用程序（快速CPU，大RAM，慢速IO）中，例如仅读取大量数据，这也可以更快。

#10 楼

当您需要对值进行乘法/除法时，您不应该使用金钱。货币的存储方式与存储整数的方式相同，而十进制存储为小数点和十进制数字。这意味着金钱在大多数情况下会降低准确性，而十进制只有在转换回原始比例时才会这样做。货币是定点的，因此其规模在计算过程中不会改变。但是，因为当它以十进制字符串形式打印时是固定点（与以2为基数的字符串中的固定位置相对），所以精确地表示了小数位数为4的值。

内部以10为基数表示小数，因此小数点的位置也以10为基数。就像金钱一样，这使得它的小数部分准确地代表了它的价值。区别在于十进制的中间值最多可以保持38位精度。

使用浮点数时，该值以二进制形式存储，就像是整数一样，十进制（或二进制，点）的位置相对于代表数字的位。因为它是二进制小数点，所以基数10的数字在小数点后立即失去精度。用这种方式无法精确表示1/5或0.2。钱和十进制都不受此限制。

将钱转换为十进制，执行计算，然后将结果值存储回money字段或变量中是很容易的。 br />从我的观点来看，我希望数字中发生的事情能够发生而不必考虑太多。如果所有计算都将转换为十进制，那么对我来说，我只想使用十进制。我将把钱字段保存起来以供显示。

从大小上看，我没有太大的改变可以改变主意。 Money占用4-8个字节，而十进制可以是5、9、13和17。这9个字节可以覆盖8个bytes货币可以覆盖的整个范围。按索引编制（比较和搜索应具有可比性）。

#11 楼

我找到了在精度主题中使用小数而不是金钱的原因。 />
FloatResult> 1

只需测试一下并做出决定即可。

#12 楼

我刚刚看到了这个博客文章：SQL Server中的资金与小数。 />对于money类型，您将获得19.30而不是19.34。我不确定是否存在将钱分为1000个部分进行计算的应用场景，但是此示例确实暴露了一些限制。