简单的回答:我建议使用十进制，精度根据您的需要。如果你想要存储整数的货币小单位(例如美分)，并且在你的编程语言中处理小数有困难，可以选择精度= 0的Decimal。

为了找到所需的精度，你需要考虑以下几点:

您支持的货币类型(它们可以有不同数量的小数)。加密货币最多有18个小数(ETH)。由于通货膨胀，小数的数量可以随着时间的推移而改变。 存储小单位商品的价格(可能是从另一种货币转换的结果)或使用累加器可能需要使用比一种货币定义的更多的小数

如果您需要更改精度，则存储最小单元的整数可能导致将来需要重新缩放值。如果用小数，就简单多了。

文章中有更多细节和注意事项。

虽然这可能有点晚，但对其他人来说是有帮助的。根据我的经验和研究，我已经知道并接受十进制(19,6)，这是在使用php和mysql时。当工作与大量的钱和汇率

简单的回答:我建议使用十进制，精度根据您的需要。如果你想要存储整数的货币小单位(例如美分)，并且在你的编程语言中处理小数有困难，可以选择精度= 0的Decimal。

为了找到所需的精度，你需要考虑以下几点:

您支持的货币类型(它们可以有不同数量的小数)。加密货币最多有18个小数(ETH)。由于通货膨胀，小数的数量可以随着时间的推移而改变。 存储小单位商品的价格(可能是从另一种货币转换的结果)或使用累加器可能需要使用比一种货币定义的更多的小数

如果您需要更改精度，则存储最小单元的整数可能导致将来需要重新缩放值。如果用小数，就简单多了。

文章中有更多细节和注意事项。

For accounting applications it's very common to store the values as integers (some even go so far as to say it's the only way). To get an idea, take the amount of the transactions (let's suppose $100.23) and multiple by 100, 1000, 10000, etc. to get the accuracy you need. So if you only need to store cents and can safely round up or down, just multiply by 100. In my example, that would make 10023 as the integer to store. You'll save space in the database and comparing two integers is much easier than comparing two floats. My $0.02.

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

Assaf的回应

这取决于你有多少钱…

听起来很轻率，但实际上是相关的。

就在今天，我们遇到了一个问题，记录未能插入到我们的Rate表中，因为其中一列(GrossRate)被设置为Decimal(11,4)，而我们的产品部门刚刚获得了一份合同，在Bora Bora的某个令人惊讶的度假胜地，每晚售价数百万太平洋法郎……这是10年前设计数据库模式时从未预料到的。