Ruby on Rails计费应用PostgreSQL小数舍入与存储问题咨询

当前数据库存储方式是否正确？ #

不正确。你当前存储的1.7249999999999999、0.13799999999999998这类值是浮点数运算产生的近似值，虽然用了PostgreSQL的decimal列，但这种存储方式违背了decimal类型设计的初衷——避免浮点精度误差。decimal列应该存储精确的十进制数值，而非无限近似的浮点结果。

是否需对Charge、S-Tax、C-Tax及Total各列均做舍入？ #

需要，但要结合业务规则和当地法规执行：

• 税务字段（S-Tax、C-Tax）：必须严格遵循对应国家的税务法规要求的精度舍入，比如部分国家要求保留2位小数，部分保留3位，不能随意处理。
• Charge字段：如果是基于费率计算的结果，需按对应国家的计费精度规则舍入后存储。
• Total字段：建议先以高精度计算各字段的累加值，再按结算/展示要求的精度舍入；或者用各字段已舍入后的值累加得到Total，具体取决于当地的结算规则。
• 注意：所有计算环节必须使用高精度十进制类型（Rails中用BigDecimal），避免用float类型引发精度丢失。

precision与scale的设置规则是什么？ #

PostgreSQL的decimal类型中，precision是数值的总位数（整数部分+小数部分），scale是小数部分的位数，设置规则如下：

• scale设置：如果业务覆盖需要2位和3位小数的国家，建议统一设置scale=4（或更高，比如6），存储高精度的原始计算值，后续在展示、结算时再按对应国家的规则舍入，避免存储时丢失精度。
• precision设置：要覆盖业务中可能出现的最大数值范围，比如产品金额最高到百万级别，可设置precision=12（7位整数+5位小数），确保不会溢出。
• Rails迁移中明确指定precision和scale，避免依赖数据库默认值，示例：

  add_column :bills, :charge, :decimal, precision: 12, scale: 4
  

是否应转为整数存储？ #

这是处理货币/计费数值的经典方案，完全避免浮点精度问题，非常推荐：

• 如果业务主要涉及2位小数的货币（比如元、美元），可以将数值转为分为单位的整数（如57.5元存为5750）；如果有需要3位小数的场景，转为毫为单位的整数（如57.5元存为57500）。
• Rails中可以用monetize gem简化单位转换、计算和展示的逻辑，减少手动处理的出错概率。

若转整数是否需先舍入？ #

是的，必须先按对应精度舍入再转换：

• 比如要转成分为单位（2位小数精度），需先将1.7249999999999999舍入为1.72，再转为整数172；如果是3位小数精度的场景，舍入为1.725再转为1725。
• 不先舍入直接截断会导致数值误差，违反计费的准确性要求。

提交时应存储何种数据才正确？ #

• 优先选择两种方式：
  1. 用decimal列存储高精度十进制值（比如scale=4），存储前按业务规则对各字段完成舍入，确保数值是精确的十进制表示，而非浮点近似值。
  2. 转为整数存储，存储舍入后的单位化整数（分/毫），确保数值完全精确。
• 前端提交时，建议传递数值的字符串形式（而非浮点数），后端用BigDecimal解析，避免传递过程中产生精度丢失。

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