NUMERIC/DECIMAL

正如Joachim
Isaksson所说，您想使用NUMERIC/DECIMAL type作为任意精度类型。

关于NUMERIC/的两个要点DECIMAL：

• 请仔细阅读文档，以了解您应该指定小数位以避免默认的小数位0，即整数值，十进制小数会丢失。虽然这是Postgres偏离标准SQL的地方之一（使您可以扩展到实现限制）。因此，不指定比例尺是一个糟糕的选择。
• 在SQL类型NUMERIC和DECIMAL是 接近，但不完全相同 根据SQL标准。在SQL：92中，将NUMERIC遵守您指定的精度，而DECIMAL数据库服务器则允许添加超出您指定精度的精度。这里再次迷路的Postgres从标准一点，既NUMERIC与DECIMAL 记录等同。

条款：

• 精度是一个数字中的位数总数。
• 刻度是小数点右边的位数（小数部分）。
• （精度-刻度）=小数点左边（整数部分）的位数。

明确项目的精度和规模规格：

• 大
  精度必须足够大，以处理将来可能需要的更大数字。意思是......也许您的应用今天能以数千美元的价格运行，但将来必须执行汇总报告，最终产生数百万美元的报告。

• 小
  出于某些会计目的，您可能需要存储最小货币金额的一小部分。含义鈥超过3个或4位小数，而不是需要一种用于在便士的2美元。

避免MONEY输入

Postgres也提供一种MONEY类型。这听起来似乎正确，但对于大多数用途而言可能并非最佳。一个缺点是，与MONEY该 刻度由数据库范围内的配置设置中设置
基于语言环境。因此，当您切换服务器或进行其他更改时，该设置可能很容易发生危险的变化。此外，您不能控制特定列的设置，而可以在每个NUMERIC类型的列上设置比例。最后，MONEY不是此标准SQL数据类型列表中所示的标准SQL。MONEY为了方便人们，Postgres包括从其他数据库系统移植数据的便利。

移动小数点

一些人采用的另一种选择是移动小数点，然后只存储在大整数数据类型中。

例如，如果存储USD美元给便士，多个任何给定的由100分数，浇铸到一个整数类型，并继续。例如，$
123.45变为整数12,345。

这种方法的好处是执行时间更快。sum在整数上执行时，诸如这样的运算非常快。整数的另一个好处是减少了内存使用量。

我发现这种方法烦人，令人困惑且具有风险。烦人的原因是计算机应该 为
我们工作，而不是对我们不利。冒险，因为某些程序员或用户可能会忽略乘/除以将其转换回小数，从而得出错误的结果。如果在没有对精确小数的良好支持的系统中工作，则此方法可能是可以接受的解决方法。

在SQL和Java中使用DECIMAL/时，移动小数点没有任何优势。NUMERICBigDecimal

四舍五入 NaN

在您的应用程序编程以及在Postgres服务器端 进行的 任何计算中，请 务必小心并注意 小数部分 的舍入和截断
。并测试是否会出现意外的NaN。

在应用程序和Postgres的两方面，始终避免使用浮点数据类型来进行理财工作。
浮点是为 提高性能 而设计的，但要以 准确性 为 代价
。计算可能会导致小数部分中看似疯狂的额外数字。对于准确性很重要的财务/金钱或其他目的而言，效果不佳。

BigDecimal

是的，在Java中，您希望将其BigDecimal作为任意精度类型。BigDecimal速度较慢，使用更多的内存，但可以准确地存储您的金额。SQL
NUMERIC/DECIMAL应该映射到此处和StackOverflow上BigDecimal讨论的位置。

BigDecimal是关于Java的最好的事情之一。我不知道任何其他具有类似类别的平台，尤其是多年来实现如此出色且经过重大改进和修复的平台。

使用BigDecimal绝对比使用速度较慢的Java鈥檚浮点类型，float及double。但是在现实世界中的应用程序中，我怀疑您的金钱计算会成为瓶颈。此外，您或您的客户还想要哪一个：
最快的 货币计算或 准确的 货币计算？馃槈

我一直认为它是BigDecimalJava中最大的轨范，它是使用Java平台的最重要的优势，而相比之下，许多其他缺少对分数的复杂支持的平台也是如此。

相似的问题：最佳货币数据类型