2017-08-24 5 views
3

Oracle(および他のいくつかのDB)にはデータ型NUMBERがあり、オプションで精度と位取りを設定できます。グループ化関数によるJDBC数値型の精度の低下を処理する方法

は、以下のクエリを仮定します

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.getPrecision(col)とjava.sql.ResultSetMetaData.getScale(col)を使用)。

これは基本的にNUMBERと同じですが、精度や位取りの指定はありません。 oracleには、NUMBER(38,12)と等しくなります。

上記の精度の低下は、SQL型をDoubleまたはIntegerに変換する必要があるかどうかを判断する上で問題になります。

これは実際にOracleのJDBCドライバのバグか、これをどう処理すべきかと思いました。 (いいえ、対応するJava型としてBigDecimalを使用することは私の選択肢ではありません)。私はあなたが任意のタイプ

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

にキャストすることができると思う

+0

元の値が 'NUMBER(12,0)'として定義されている可能性があるため、その平均値が同じ型である必要はありません。実際には、最高の精度で平均を取る必要がある場合、それはかなり悪いことになります。平均を特定のタイプにキャストすることができます。 – Kayaman

+0

合意。しかし、JDBCはフィールドの最大精度とスケールを返すべきではありません(Oracleは内部的にそれを扱います)。 –

+0

私はそう思います。 'ResultSetMetaData.getColumnType()'を介して)実際に 'Types.NUMERIC'列の型ですか? – Kayaman

答えて

2

the example

を参照してくださいSQL AVG()関数は、デフォルトの小数点以下の桁数と平均値を返します。 CAST()は、値の小数点以下桁数を増減するために使用されます。 CAST()関数は、小数点データ型と数値データ型を変換する際の小数点以下の桁数を維持する上で非常に優れています。 'AS DECIMAL'に続けて書式指定を指定すると、CAST()で小数点以下の桁数を数値で指定するために使用されます。

+0

しかし、それでも、オラクルがスケールと精度を0として返す理由は、内部的にこれらの2つの使用可能な最大値(38,12)を使用しています。 –

+0

私は結果に基づいてフライでスケールと精度を計算すると思います。例えば。 NUMBER(1)があり、10行を合計すると、結果は10KBの場合はNUMBER(2)になる可能性があります。しかし、私の推測では、どんなドキュメントにも言及していません。 – StanislavL

2

これは、Postgresドライバpostgresql-9.4-1204-jdbc42.jarの同様の動作に基づく推測です。

不特定の場合、NUMERICのデータベースでは、列の精度と位取りに関する特定の情報は保存されていないようです。これにより、データベースは、それが適合していると思われる方法で内部的に値を格納することができます。任意の精度またはスケール無しhttps://www.postgresql.org/docs/current/static/datatype-numeric.html

から精密に実装限界まで(131072桁まで小数点の前に、任意の精度とスケールの数値が格納可能なカラムを作成し、16383個の数字までをドライバサーバーの実装固有の最大値が何であるかを知らない

ので)小数点以下は、実際の値を返すことはできません。それは実際の値を知らないことを示すために0を返し、推測された推測を望まない。

same with Oracleのように見えます。最大精度は高くなるかもしれませんが、移植性は38桁まで保証されます。

Oracle Databaseを稼働している異なるシステム間で、最大38桁の精度で格納され、ポータブルであることが保証されています。

StanislavLのように問題を解決するには、キャスティングによって特定の精度/スケールに値を強制することができます。

+0

良い調査!私たちの推測は合理的だと思われる。 +1 – StanislavL

関連する問題