1

SQL Server 2008 には 3 つのテーブルがあります。

  1. 取引注文
  2. transact_shipments
  3. transact_child_orders.

それらのうちの 3 つには、共通の列Carrying_costがあります。データ型は 3 つのテーブルすべてで同じです。NUMERIC_PRECISION 53 と NUMERIC_PRECISION_RADIX 2 の float です。

  1. テーブル 1 - transact_orders では、この列の値は 3 行で 5.1 です。convert(decimal(20,15), Carrying_cost) は5.100000..... を返します。

  2. 表 2 - transact_shipments の 3 つの行は、transact_orders のこれらの 3 つの行から Carrying_cost をフェッチしています。convert(decimal(20,15), Carrying_cost) は5.100000..... ここでも戻ります。

  3. 表 3 - transact_child_orders は、transact_shipments からのこれら 3 つの維持費を合計しています。そこに表示される値は15.3、通常の選択を実行したときのものです。

しかし、この厩舎にconvert(decimal(20,15), carrying_cost)戻ります。そして、UIでも15.299999999999999その値を示しています。precision gainedui は値をフェッチするだけですが、変換は行いません。Java コードでは、db から値をフェッチする変数は として定義されていdoubleます。

3 つの Carrying_costs を合計するステップ 3 のコードは単純です::

... sum(isnull(transact_shipments.carrying_costs,0)) sum_carrying_costs,... ...

この変更が 3 番目のステップで発生する理由は何ですか? どんな助けでも大歓迎です。さらに情報が必要な場合はお知らせください。

4

1 に答える 1

1

たくさんのコメントを投稿するのではなく、答えを書きます。


浮動小数点数は、丸め誤差を受け入れることができない正確な値には適していません-たとえば、財務。

フロートは、非常に小さい数から非常に大きい数までスケーリングできます。しかし、彼らはある程度の精度を失うことなくそれをしません。あなたはオンラインで詳細を調べることができます、あなたが読むためにそこにたくさんの良い仕事があります。

しかし、単純に言えば、それは真の2進数であるためです。一部の10進数は、100％の精度で2進数として表すことができない場合があります。 （1/3のように、10進数で100％の精度で表すことはできません。）


DECIMALデータ型でパフォーマンスの問題が発生している原因がわかりません。多くの場合、暗黙的な変換が行われていることが原因です。 （どこかにフロートがあるか、定義が異なる小数などがあります）

しかし、原因に関係なく。整数演算よりも速いものはありません。だから、あなたの値を整数で保存しますか？ £1.10として保存できます110p。または、何らかの理由でペンスの端数が得られることがわかっている場合は、11000dp （deci-pennies）。

次に、これまでに到達する最大の価値と、それがより適切かどうINTかを検討する必要があります。BIGINT

また、整数を使用する場合は、除算に注意してください。£103人に分ける場合、最後はどこ1pに行く必要がありますか？ £3.33二人と£3.34一人のために？ £0.01銀行に食べられた？しかし、常に、それは取得するべきではありませんlost to the digital elves。

そして、明らかに、ユーザーに番号を提示するときは、 ;£ではなく元に戻す必要があります。dpしかし、とにかくそれを頻繁に行う必要があり£10kます£10M。


何をするにしても、浮動小数点値による丸め誤差が必要ない場合は、FLOATを使用しないでください。

（フロートの使用方法、さらに重要なのは使用しない方法についてオンラインで書かれたALOTがあります。これは大きなトピックです。「非常に正確で、驚くべきことで、何でもできる」という罠にはまらないでください。残念ながら一般的ですが素朴な仮定を使用して、人々がデータを台無しにした回数を数えることはできません。）

于 2012-06-08T11:21:05.117 に答える