如何处理由于分组函数而导致的JDBC数字类型精度损失

Question

Oracle（和其他一些DB）有一个数据类型NUMBER，可以选择设置精度和规模。

假设以下查询：

SELECT agent_code, 
AVG (opening_amt)
FROM customer 
GROUP BY agent_code;

如果上述查询中的两个字段都定义为NUMBER（12,0），则JDBC中的结果确实是agent_code，但在AVG（opening_amt）上，精度和刻度都返回0（通过java.sql.ResultSetMetaData.get精度（col）和java.sql.ResultSetMetaData.get刻度（col）。

这基本上与NUMBER相同，没有任何精度或比例规范，根据甲骨文，将等于NUMBER（38,12）。

上面的精度损失给我一个问题来确定sql类型是否应该转换为双精度或整数。

所以，我想知道这是否是Oracle JDBC驱动程序中的一个bug，或者应该如何处理？（不，使用BigDecimal作为对应的java类型不是我的选择）。

Answer 1

我认为你可以选择任何类型

CAST(AVG(opening_amt) AS DECIMAL(12,2))

参见示例

SQLAVG（）函数返回具有默认小数位的平均值。CAST（）用于增加或减少值的小数位。CAST（）函数在转换小数和数字数据类型时更好地保留小数位。格式规范后跟的“AS DECIMAL”与CAST（）一起用于将数值转换为特定的小数位值。

Answer 2

这是基于Postgres驱动程序postgresql-9.4-1204-jdbc42中类似行为的推测。jar。

对于未指定的数值，数据库似乎没有存储有关列精度和比例的任何特定信息。这允许数据库以任何合适的方式在内部存储值。从…起https://www.postgresql.org/docs/current/static/datatype-numeric.html

如果没有任何精度或比例，则创建一列，其中可以存储任何精度和比例的数值，最高可达精度的实现限制（小数点前最多131072位；小数点后最多16383位）

由于驱动程序不知道服务器的具体实现最大值是多少，因此无法返回实际值。它返回0表示它不知道实际值，也不想进行任何有根据的猜测。

Oracle的情况似乎也是如此。最大精度可能更高，但最多只能保证38位的可移植性。

可以存储几乎任何数量级的数字，并保证可在操作Oracle数据库的不同系统之间移植，精度高达38位。

至于解决问题中的问题，如StanislavL所示，可以通过铸造将值强制到特定的精度/比例。