Java与PostgreSQL中货币汇率两种存储计算方案的潜在问题咨询

方案1：整数缩放存储（×10^7，Java long / PostgreSQL BIGINT） #

舍入问题 #

• 转换阶段的强制舍入：如果原始数值小数位超过7位（比如1.12345678），乘以10^7后会出现小数部分，转long或BIGINT时必须舍入。若Java端与数据库端采用不同的舍入规则（比如Java默认截断、PostgreSQL默认银行家舍入），会导致数据不一致。
• 计算后的舍入误差累积：汇率换算时，两个缩放后的整数相乘/相除后需要再缩放回原始比例，多次计算后舍入误差会累积，比如多笔小额交易叠加后，最终结果可能和预期有偏差。

溢出问题 #

• 单值存储溢出：Java long和PostgreSQL BIGINT的最大值为9223372036854775807，对应原始数值上限约为922337203.6854776。如果业务中出现大额交易、超高汇率的货币，直接存储会触发溢出报错。
• 计算过程溢出：两个大整数相乘时（比如接近上限的数值相乘），会直接超出long范围，抛出ArithmeticException（Java）或数据库报错，极端业务场景下仍可能触发。

方案2：原始数值存储（Java BigDecimal / PostgreSQL numeric(18,7)） #

舍入问题 #

• 存储时的自动舍入：PostgreSQL numeric(18,7)固定保留7位小数，插入的数值若小数位超过7位，会按数据库默认规则舍入。如果Java端BigDecimal未提前按相同规则舍入，会导致存储值与内存中值不一致。
• 计算时的舍入要求：BigDecimal进行除法等可能产生无限小数的运算时，必须显式指定舍入模式，否则会直接抛出ArithmeticException。若舍入模式选择不符合业务规则（比如银行要求四舍五入到分，但这里保留7位），会出现不符合预期的精度损失。
• 浮点数转BigDecimal的隐性误差：如果用double类型构造BigDecimal（比如new BigDecimal(0.1)），由于double是二进制浮点数，会存储近似值，后续计算会引入隐性精度误差。

溢出问题 #

• 数据库端存储溢出：PostgreSQL numeric(18,7)总位数为18，整数部分最多11位（即最大值99999999999.9999999），超出该范围的数值插入时会直接报错。
• Java端无原生溢出，但转换有风险：BigDecimal本身是任意精度类型，计算不会溢出，但如果需要转换为long等固定范围类型时，仍可能触发溢出；极端大的数值会占用更多内存，但业务场景中极少出现。

内容的提问来源于stack exchange，提问作者anon