SQL ServerでMONEYまたはDECIMAL（x、y）データ型を選択する必要がありますか？

moneyデータ型とdecimal(19,4)（お金が内部で使用するものである）のようなものとの間に実際の違いがあるかどうかについて私は興味があります。

これはmoneySQL Serverに固有のことです。どちらか一方を選択する説得力のある理由があるかどうか知りたい。ほとんどのSQL Serverサンプル（AdventureWorksデータベースなど）は価格情報moneyなどではなくdecimal、使用します。

moneyデータ型を引き続き使用する必要がありますか、それとも代わりにdecimalを使用する利点はありますか？お金はタイプする文字数が少ないですが、それは正当な理由ではありません:)

決してお金を使うべきではありません。正確ではなく、純粋なゴミです。常に10進数/数値を使用してください。

これを実行して、私の意味を確認します。

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

出力：2949.0000 2949.8525

あなたがお金をお金で割らないと言った人々の一部へ：

これが相関を計算するための私のクエリの1つであり、それをお金に変更すると間違った結果が得られます。

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id

SQLMenaceはお金が不正確であると言いました。しかし、あなたはお金をお金で乗算/除算しないでください！3ドル×50セントはいくらですか？150ドルセント？お金を10進数であるスカラーで乗算/除算します。

DECLARE
@mon1 MONEY,
@mon4 MONEY,
@num1 DECIMAL(19,4),
@num2 DECIMAL(19,4),
@num3 DECIMAL(19,4),
@num4 DECIMAL(19,4)

SELECT
@mon1 = 100,
@num1 = 100, @num2 = 339, @num3 = 10000

SET @mon4 = @mon1/@num2*@num3
SET @num4 = @num1/@num2*@num3

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

正しい結果になります：

moneyresult numericresult
--------------------- ----------------------------- ----------
2949.8525 2949.8525

money10進数で4桁を超える必要がなく、スカラー（お金を表すものではない）がdecimalsであることを確認する限り、これは適切です。

何をしているのか分からないと危険です

高精度の10進数型でさえ、1日を節約することはできません。

declare @num1 numeric(38,22)
declare @num2 numeric(38,22)
set @num1 = .0000006
set @num2 = 1.0
select @num1 * @num2 * 1000000

1.000000 <-0.6000000である必要があります

moneyタイプは整数であり、

テキストの表現smallmoneyとdecimal(10,4)似ているかもしれませんが、その彼らは互換がありません。日付が保存されているのを見るとうんざりしますvarchar(10)か？これは同じことです。

舞台裏では、money/ smallmoneyは単なるbigint/ですint 。のテキスト表現の小数点moneyは、yyyy-mm-dd日付のダッシュのように、視覚的な綿毛です。SQLは実際にはそれらを内部に格納しません。

decimalvs についてmoneyは、ニーズに適したものを選択してください。moneyユニットの1 /第万の整数倍として会計値を記憶するためのタイプが存在する非常に一般的です。また、単純な加算と減算を超えて実際のお金と計算を扱っている場合、データベースレベルでそれを行うべきではありません！Banker's Rounding（IEEE 754） をサポートするライブラリを使用して、アプリケーションレベルで実行します。

WayneMがお金はSQL Serverに固有であることを知っていると述べたことを私は理解しています。ただし、10進数でお金を使用する理由、またはその逆の理由があるかどうかを尋ねています。1つの明白な理由がまだ述べられている必要があると私は思います。 -起こり得ること。

システムを可能な限り柔軟にします！

まあ、私は好きMONEYです！これは1バイトよりも安価DECIMALであり、（カバーの下で）加算および減算演算は本質的に整数演算であるため、計算はより高速に実行されます。@SQLMenaceの例（いつの間にか警告ですINT）は、結果がゼロになるであろうegersにも同様に適用できます。しかし、それが適切な場合は整数を使用しない理由にはなりません。

したがって、これは完全に「安全」であり、MONEY対処しているMONEY場合に使用し、それが従う数学的規則（INTeger と同じ）に従って使用するのが適切です。

SQL Server MONEYがDECIMALsのs（またはFLOATs）への除算と乗算を促進したほうがよかったのではないでしょうか。おそらくそうすることを選択しませんでした。彼らはそれらを分割するときにINTエガーをFLOATsに昇格させることもしなかった。

MONEY精度の問題はありません。DECIMALのは、計算時に使用される、より大きな中間のタイプを持って取得すると、そのタイプを使用するだけの「機能」です（と私は「機能」を拡張していることを確認してくださいどこまで実際にはありませんよ）。

特定の質問に答えるために、「説得力のある理由」？あなたが絶対最大のパフォーマンスをしたい場合はまあ、SUM(x)どこxもどちらかの可能性DECIMALやMONEY、その後、MONEYエッジを持っています。

また、これは小さいいとこ（SMALLMONEY4バイトのみ）であることも忘れないでください214,748.3647。

より大きな中間型の使用に関する要点を証明するために、中間体を変数に明示的に割り当てるとDECIMAL、同じ問題が発生します。

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

生成2950.0000大丈夫なので、少なくとも（DECIMALというよりも丸みを帯びましたMONEY、整数と同じられます）。

非常によく似た問題に遭遇したばかりで、トップレベルのプレゼンテーション以外でMoneyを使用したことがないという点で、私は非常に+1になっています。複数のテーブル（事実上、売上伝票と売上請求書）があり、それぞれに履歴上の理由で1つ以上のMoneyフィールドが含まれており、合計請求書税のどれだけがそれぞれに関連しているかを計算するために比例計算を実行する必要があります販売伝票の行。私たちの計算は

vat proportion = total invoice vat x (voucher line value / total invoice value)

これにより、実際のお金/お金の計算が行われ、除算部分でスケールエラーが発生し、それが乗算されて不正確なバットの比率になります。これらの値が後で追加されると、合計請求書値に加算されないバット比率の合計になります。大括弧内の値のいずれかが小数であった場合（そのようにそれらの1つをキャストしようとしています）、バットの比率は正しいでしょう。

元々ブラケットがなかったとき、これは以前は機能していましたが、関係する値が大きいため、より高いスケールを効果的にシミュレートしたと思います。かっこを追加したのは、最初に乗算を行っていたためです。まれに、計算に使用できる精度が下がる場合がありましたが、これにより、この一般的なエラーが発生しています。

他の回答の一般的な推力への対抗点として。お金の多くの利点をご覧ください…データタイプ！にリレーショナルエンジンにSQLCATガイド

具体的には次のことを指摘します

顧客の実装に取り​​組み、お金のデータ型に関するいくつかの興味深いパフォーマンス数値を見つけました。たとえば、Analysis ServicesがSQL Serverのmoneyデータ型と一致するように通貨データ型（doubleから）に設定された場合、処理速度（行/秒）が13％向上しました。SQL Server Integration Services（SSIS）内で30分未満で1.18 TBをロードするパフォーマンスを高速化するには、SSIS 2008-世界記録のETLパフォーマンスで指摘されているように、4つのdecimal（9,2）列をTPC-H LINEITEMテーブルの5バイトからマネー（8バイト）への一括挿入速度の向上20％...パフォーマンスの向上の理由は、SQL Serverの表形式データストリーム（TDS）プロトコルが原因です。これは、データをコンパクトなバイナリ形式で転送し、SQL Serverの内部ストレージ形式にできるだけ近づけるという主要な設計原則を備えています。経験的に、これはSSIS 2008-Kernrateを使用した世界記録のETLパフォーマンステスト中に観察されました。データ型が小数からマネーに切り替えられたとき、プロトコルは大幅に低下しました。これにより、データの転送が可能な限り効率的になります。複雑なデータ型は、固定幅型よりも、処理するために追加の解析とCPUサイクルが必要です。

したがって、質問に対する答えは「依存する」です。精度を維持するために、特定の算術演算をより注意深くする必要がありますが、パフォーマンスを考慮すると、これに価値があることがわかります。

MONEYとNUMERICALの別の見方を示したいと思います。主に自分の専門知識と経験に基づいています...ここでの私の見方はMONEYです。私はかなり長い間これを扱っており、実際にNUMERICALをあまり使用していません。 。

お金のプロ：

• ネイティブデータタイプ。CPUレジスタ（32または64ビット）と同じネイティブデータ型（integer）を使用するため、計算に不要なオーバーヘッドが必要ないため、計算が小さくて高速です。です。MONEYには8バイトとNUMERICAL（19、4 ）9バイトが必要（12.5％大きい）...

  お金はそれが（お金として）意図されたものである限り、より高速です。どのくらい速いのか？SUM100万件のデータに対する私の簡単なテストでは、MONEYが275ミリ秒、NUMERICが517ミリ秒であることが示されています。これは、ほぼ2倍の速さです。なぜSUMテストなのですか。次のプロポイントを見る

• お金に最適。MONEYは、たとえば会計など、お金を貯めて操作を行うのに最適です。1つのレポートで、数百万の加算（SUM）と、SUM操作の完了後にいくつかの乗算を実行できます。非常に大きな会計アプリケーションでは、ほぼ2倍の速さで、非常に重要です...
• お金の精度が低い。実際のお金はそれほど正確である必要はありません。つまり、多くの人は1セント米ドルを気にするかもしれませんが、0.01セント米ドルはどうでしょうか。実際、私の国では、銀行はセント（10進数のコンマの後の数字）を気にしません。米国の銀行や他の国については知りません...

お金のコン：

• 限定精度。MONEYは4桁（カンマの後）の精度しかないため、除算などの演算を行う前に変換するmoney必要があります...しかし、ここでもそれほど正確である必要はなく、単なる金額ではなく、お金として使用するためのものです。数...

しかし...大きいですが、ここでも実際のお金が関係するアプリケーションがありますが、会計などの多くのSUM操作では使用しないでください。代わりに多くの除算と乗算を使用する場合は、お金を使用しないでください...

これまでのすべての投稿には有効なポイントがありますが、質問に正確に答えない人もいます。

問題は、正確性の低いデータ型であり、複雑な計算で使用するとエラーが発生する可能性があることがわかっているのに、なぜ誰かがお金を好むのでしょうか。

複雑な計算を行わず、この精度を他のニーズと交換できる場合は、お金を使います。

たとえば、これらの計算を行う必要がなく、有効な通貨テキスト文字列からデータをインポートする必要がある場合。この自動変換は、MONEYデータ型でのみ機能します。

SELECT CONVERT(MONEY, '$1,000.68')

独自のインポートルーチンを作成できることを知っています。ただし、世界中の特定のロケール形式でインポートルーチンを再作成したくない場合もあります。

別の例として、これらの計算を行う必要がなく（値を格納するだけでよい）、1バイトを節約する必要がある場合（moneyは8バイト、decimal（19,4）は9バイト）。大量のデータを読み取るだけのような一部のアプリケーション（高速CPU、大容量RAM、低速IO）では、これも高速になる場合があります。

値に乗算/除算を行う必要がある場合は、お金を使うべきではありません。お金は整数と同じ方法で格納されますが、10進数は小数点と10進数として格納されます。つまり、ほとんどの場合、お金は精度を落としますが、10進数は元のスケールに変換されたときにのみ下がります。Moneyは固定小数点なので、計算中にスケールは変わりません。ただし、10進数の文字列として出力されるときは固定小数点であるため（基数2の文字列の固定位置としてではなく）、スケール4までの値が正確に表現されます。したがって、足し算と引き算については、お金で結構です。

小数点は10進数で内部的に表現されるため、小数点の位置も10進数に基づいています。これにより、金額の場合と同様に、小数部分がその値を正確に表します。違いは、10進数の中間値は最大38桁の精度を維持できることです。

浮動小数点数では、値は整数のように2進数で格納され、10進数（または2進数、ahem）の位置は、数値を表すビットを基準にしています。2進小数点であるため、10を底とする数値は小数点の直後で精度を失います。1/5、つまり0.2は、この方法では正確に表すことができません。お金も小数もこの制限の影響を受けません。

moneyをdecimalに変換し、計算を実行し、結果の値をmoneyフィールドまたは変数に格納するのは簡単です。

私の視点から、私は数字に起こることを、それらにあまり多くの考えを与える必要なしに起こるようにしたいです。すべての計算が10進数に変換される場合、私には10進数を使用したいと思います。表示用にmoneyフィールドを保存します。

サイズ的には、考えを変えるほどの違いは見当たりません。Moneyは4〜8バイトかかりますが、10進数は5、9、13、および17になる可能性があります。9バイトは、8バイトのMoneyが扱える範囲全体をカバーできます。索引ごと（比較と検索は比較可能でなければなりません）。

精度の問題で、小数よりも小数を使用する理由を見つけました。

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

DecimalResult> 1.000000

MoneyResult> 0.9999

FloatResult> 1

ただそれをテストして、あなたの決定をしてください。

私はこのブログエントリを見ました：SQL Serverのマネーと小数です。

基本的にお金には精度の問題があると言っています...

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

moneyタイプについては、19.34ではなく19.30を取得します。お金を計算のために1000の部分に分割するアプリケーションシナリオがあるかどうかはわかりませんが、この例ではいくつかの制限が明らかになっています。