SQL Server 200x を使用するプロジェクトを継承しました。このプロジェクトでは、問題のドメインで常にパーセンテージと見なされる値を格納する列が、10 進数の 1 より大きい値として格納されます。たとえば、70% (文字どおり 0.7) は70として格納され、100%は100として格納されます。取得した値に対して * 0.01 を、値を永続化する前に * 100 を覚えておく必要があることを除けば、問題にはならないようです。それ自体で。それは私の頭を爆発させます...それで、私が行方不明になる正当な理由はありますか? 疑似パーセンテージで動作するように書かれたかなりの量のコードがあることを考えると、それを修正する説得力のある理由はありますか?
100% を超える場合がいくつかありますが、たとえば、そのような場合に値が 1.05 として保存されない理由がわかりません。
編集: 頭の調子が良くなり、少し頭が良くなりました。すべての洞察に感謝します。
バイトフィールドの場合、浮動小数点数よりもデータベース内のスペースが少なくなりますが、何百万ものレコードがない限り、違いはほとんどわかりません。
実際には、浮動小数点数ではなく整数のパーセンテージ値を保存し、それを使用して計算したいと考える理由が 4 つあります。
decimal型と同等のデータ型があるわけではないことに注意してください)。主値も整数である場合、
principle * integerPercentage / 100
すべての整数演算を使用する方が、通常、同等の浮動小数点よりも高速です ( T-SQL の型と同等の浮動小数点型の場合は、かなりdecimal高速になる可能性があります)。
浮動小数点値は等しいかどうかを比較できないため、SQL を単純にするために整数が使用された可能性があります。
例えば
(0.3==3*.1)
通常は False です。
でも
abs( 0.3 - 3*.1 )
小さな数 (5.55e-17) です。(column-SomeValue) BETWEEN -0.0001 AND 0.0001しかし、すべてをorで行わなければならないのは苦痛ABS(column-SomeValue) < 0.0001です。column = SomeValueWHERE 句で行うことをお勧めします。
浮動小数点数は丸め誤差が発生しやすいため、比較で「おかしな」動作をする可能性があります。常に固定小数点として扱いたい場合は、10 進数の型 (decimal(5,2)) を選択するか、変換して int として保存するか、db が行うようにすることができます。int の方が占有するスペースが少なくても、おそらく 10 進法を使用します。
良い推測は、整数で行うこと (保存、計算、ユーザーの編集への詰め込みなど) は、浮動小数点数で同じことを行うよりもわずかに簡単で効率的であるためです。また、丸めの問題は、データを見るとそれほど明白ではありません。
これらがエンドユーザーに表示され、操作される可能性が高い数値である場合、パーセンテージは小数よりも理解しやすいです。
これは、表記法が役立つ状況の1つです。プログラムでは、接頭辞（ハンガリー語）または接尾辞を一貫して使用して、パーセンテージの値と10進数の値を指定します。命名規則をデータベースフィールド自体に拡張できる場合は、はるかに優れています。
また、データストレージの問題に加えて、実行している処理に整数演算を使用できる場合、浮動小数点演算を実行する場合よりもパフォーマンスが大幅に向上します。したがって、整数値として整数を格納すると、処理ロジックが反復可能になる場合があります。整数演算
それらを実際に係数として使用している場合（またはデータベースのユーザーがレポートでこの種のことを行うことを期待している場合）、特に複数の計算を行う理由がある場合は、それらを係数として保存する場合があります。
ただし、これを行う場合は、すべてのパーセンテージまたはすべての係数のいずれかで一貫している必要があります。