0

彼の更新クエリで問題に直面しています。balance1 フィールドを 6442450941.026600 に更新しています。

update account_subscriber set total_balance1=6442450941.026600
 where SUB_ID='xyz'

しかし、結果は以下のようになります（select stmtを起動した後、取得します）

TOTAL_BALANCE1 6442450941.02659988

2番目のシナリオ：次の値で更新しましょう

update account_subscriber set total_balance1=6442450941.4567
 where SUB_ID='xyz'

結果は 6442450941.45670032 です。

精度が変化する理由を理解するのを手伝ってください。

Sql*plus のバージョンは 10.2.0.3.0 です

ありがとう、チャンドラ・ブーシャン・バクシ

4

4 に答える 4

3

私が思いつく唯一の説明は、データベースとデータベースが表示されている場所との間のパスのどこかで、浮動小数点値に変換されているということです。私は自分の Oracle 開発ツールに PL/SQL Developer を使用しており、非常に信頼できると考えています。以下を実行したときの驚きを想像してみてください。

create TABLE rpj_test (val number(22, 8));

INSERT INTO rpj_test(val) VALUES (6442450941.026600);

SELECT * FROM rpj_test;

あなたが報告した正確な結果を得ました (6442450941.02659968)。なんと!?!?

しかし、その後、重要な質問を自問しました。これをテストして、正しいデータが実際にデータベースにあることを確認するにはどうすればよいでしょうか? そこで、次のクエリを実行しました。

SELECT val * 10000 FROM rpj_test;

私が期待した答えを得ました（64424509410266）。

したがって、データベース内のデータは正しいようです。そこに驚きはありません - 私は、オラクルの NUMBER 型が製品の最も優れた無視された機能の 1 つであると考えています。 ）。私の目には、これは浮動小数点の変換エラーのように見えます。どうすればよいでしょうか? そこで、PL/SQL Developer の [Preferences] 構成ダイアログを調べてみると、[SQL Window] タブに "Number fields to_char" というタイトルの小さな設定がありましたが、チェックされていませんでした。これを確認し、最初の SELECT クエリを再実行したところ、見よ、データが期待どおりに表示されました。

物語の教訓：

  1. NUMBER は正しく計算および格納されます。バグを見つけたと思っ たら、何度も何度も真剣に考えてください。16 通りの方法でテストします。これが実際にはバグではないことをどのように証明できるかを考えてください。
  2. 使用するツールは、得られる結果に影響します。

共有してお楽しみください。

于 2012-08-23T17:22:07.003 に答える
0

受信列のデータ型によって必要な精度に解決できない値を指定しています。質問が示すように、 100 万分の 1までの精度が必要な場合は、テーブル フィールドのデータ型の精度を確認し、それに応じて調整する必要があります。

于 2012-08-23T13:22:03.183 に答える
0

不正確なデータ型を使用しているためです。

于 2012-08-23T13:22:16.017 に答える
0

これは、pl/sql 開発者の表示の問題です。PL/SQL 開発者で、[ツール] メニューと [プリファレンス] オプションを選択し、[SQL ウィンドウ タイプ] と [数値レイアウト] で、フォーマットされたオプションのチェックを外し、他のオプションを選択して、正しい結果を確認します。:)

于 2012-08-23T15:40:18.830 に答える