我意识到WayneM已经声明他知道钱是特定的SQL Server。然而，他问是否有任何理由使用货币而不是十进制，反之亦然，我认为一个明显的原因仍然应该说明，那就是使用十进制意味着如果你不得不改变你的DBMS，它可以减少一件担心的事情——这是可能发生的。

使您的系统尽可能灵活!

我找到了在精确度科目中使用十进制而不是货币的原因。

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

十进制结果 > 1.000000

MoneyResult > 0.9999

FloatResult > 1

只需测试一下，然后做出决定。

SQLMenace说钱是不精确的。但是你不能把钱乘以/除以钱!3美元乘以50美分等于多少?150 dollarcents ?你用标量乘(除)钱，结果应该是小数。

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

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

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

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

结果在正确的结果:

moneyresult           numericresult
--------------------- ---------------------------------------
2949.8525             2949.8525

钱是好的，只要你不需要超过4个十进制数字，你要确保你的标量(不代表钱)是小数。

You shouldn't use money when you need to do multiplications / divisions on the value. Money is stored in the same way an integer is stored, whereas decimal is stored as a decimal point and decimal digits. This means that money will drop accuracy in most cases, while decimal will only do so when converted back to its original scale. Money is fixed point, so its scale doesn't change during calculations. However because it is fixed point when it gets printed as a decimal string (as opposed to as a fixed position in a base 2 string), values up to the scale of 4 are represented exactly. So for addition and subtraction, money is fine.

小数点内部以10为底表示，因此小数点的位置也以10为底数为基础。这使得它的小数部分准确地代表了它的值，就像货币一样。不同之处在于十进制的中间值可以保持38位的精度。

对于浮点数，值以二进制形式存储，就像它是一个整数一样，并且小数点(或二进制，嗯，)点的位置相对于表示该数字的位。因为它是一个二进制小数点，以10为基数的数字在小数点后失去精度。1/5，或0.2，不能用这种方式精确地表示。货币和十进制都不受这个限制。

将货币转换为十进制，执行计算，然后将结果值存储回货币字段或变量中，这非常简单。

从我的角度来看，我希望发生在数字上的事情不需要太多思考就能发生。如果所有的计算都要转换成十进制，那么对我来说，我只想用十进制。我会保留money字段用于显示。

就尺寸而言，我看不出有多大差别来改变我的想法。Money需要4 - 8个字节，而decimal可以是5、9、13和17。9个字节可以覆盖8个字节的货币所能覆盖的全部范围。索引方面(比较和搜索应该具有可比性)。

我们刚刚遇到了一个非常相似的问题，我现在非常+1，因为除了在顶级演示中，我从不使用Money。我们有多个表(实际上是一个销售凭证和一个销售发票)，由于历史原因，每个表都包含一个或多个Money字段，我们需要按比例计算出总发票中有多少Tax与销售凭证上的每一行相关。我们的计算是

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

这将导致现实世界中的货币/货币计算，从而导致在分割部分上的刻度错误，然后乘以一个不正确的增值税比例。当这些价值随后相加时，我们最终得到的是增值税比例的总和，加起来不等于发票总价值。如果括号中的任何一个值是小数(我将把其中一个转换为小数)，vat比例将是正确的。

当括号不存在的时候，原来这是工作的，我猜是因为涉及到更大的值，它有效地模拟了一个更高的规模。我们添加括号是因为它先做乘法运算，这在一些罕见的情况下会破坏计算的精度，但这现在已经导致了这个更常见的错误。

作为对其他答案主旨的反驳。看金钱的诸多好处…数据类型!在SQLCAT的关系引擎指南中

我要具体指出以下几点

Working on customer implementations, we found some interesting performance numbers concerning the money data type. For example, when Analysis Services was set to the currency data type (from double) to match the SQL Server money data type, there was a 13% improvement in processing speed (rows/sec). To get faster performance within SQL Server Integration Services (SSIS) to load 1.18 TB in under thirty minutes, as noted in SSIS 2008 - world record ETL performance, it was observed that changing the four decimal(9,2) columns with a size of 5 bytes in the TPC-H LINEITEM table to money (8 bytes) improved bulk inserting speed by 20% ... The reason for the performance improvement is because of SQL Server’s Tabular Data Stream (TDS) protocol, which has the key design principle to transfer data in compact binary form and as close as possible to the internal storage format of SQL Server. Empirically, this was observed during the SSIS 2008 - world record ETL performance test using Kernrate; the protocol dropped significantly when the data type was switched to money from decimal. This makes the transfer of data as efficient as possible. A complex data type needs additional parsing and CPU cycles to handle than a fixed-width type.

所以这个问题的答案是“视情况而定”。对于某些算术操作，您需要更加小心，以保持精度，但您可能会发现，出于性能考虑，这样做是值得的。