SQL Server Decimal（9、0）vs INT

顧客の1人がDECIMAL(18,0)、SQL Server 2008R2データベースのデータ型を一部の列に使用しています。列の成長が非常に遅いため、彼は最近、データ型を変更してDECIMAL(5,0)ストレージを回復することを提案しました。

MSDNライブラリによると、DECIMAL(5,0)データ型の記憶領域は、データ型と同様DECIMAL(9,0)に5バイトです。INT1バイト小さくなりますが、格納できる-99,999〜99,999の代わりに-2 ^ 31〜2 ^ 31の範囲ですべてをDECIMAL(5,0)格納できます。DECIMAL5バイト（DECIMAL(9,0)）に収まる最大サイズでも、-999,999,999から999,999,999の範囲の整数のみを格納できます（INT4バイトで提供される範囲の半分未満です）。

DECIMALover を使用することの2つの「メリット」を考えることができますINT。

後でストレージ容量を使用せずにスケールを追加する機能
データ型を変更せずに、38桁まで精度をスケーリングする機能

しかし、これらは私の意見では本当の利点ではありません：

整数へのスケールの追加は、ごくわずかな場合にのみ意味があります（スケールが違いを生むほとんどの場合、事前に追加することもできます）
SQL Serverは、すべての精度/スケールの組み合わせを異なるデータ型と見なします。そのため、精度またはスケールを増やしても、データ型はそのままではありません。

これは私に疑問を抱かせます：DECIMAL(5,0)整数のデータ型の追加の利点は何ですか？

sql-server t-sql datatypes

— VSTRIEN
ソース

1つの利点は、5桁の制限です。しかし、このような変更でどのくらいのストレージ容量を節約できるのでしょうか。

— -dezso

IMO、列の値が範囲内に収まることを確認する必要がある場合は、チェック制約を使用します。ここで考慮すべきことは、この列が将来小数値を必要とする可能性がある場合のみだと思います。

— ジョンセイゲル

記憶域が心配な場合は、これよりも圧縮を使用する方が適しています。int / bigintの代わりにdecimal（x、0）を使用しても具体的な利点はありません。

— ロバートLデイビス

decimal(x,0)と整数型とのもう1つの違いは、算術除算で示されます。intをintで除算すると、intが得られます。decimal（x、0）をintで除算すると、decimal（x + 6,6）が得られます。

— アンドリーM

@AndriyM、これは最大のメリットだと思います。コメントではなく回答に言い換えれば、回答としてマークします。

— -vstrien

回答:

DECIMAL（9、0）とINTまたはDECIMAL（18、0）とBIGINTを比較している限り、ストレージスペースに関して実質的な利点はないことに同意します。（1バイト以内。）

処理に関しては、@ Andriyが言うように、10進数は小数部分を失わないタイプに自然に分割されます（それが重要な場合）。

一方、多くのSUM（）または比較（値の検索など）を実行している場合、ネイティブINT型の操作はCPUによってより効率的にパイプライン化されるため、数値の観点からはるかに高速です。int比較は2つのアセンブリオペコード（MOV、CMP）ですが、10進数の比較は非常に多くなります。

— クリス・チャブ
ソース

答えは理にかなっていますが、プロセッサにはデータ型の知識がありません。したがって、4バイトの1つのデータ型は、4バイトの別のデータ型と同じ速さで比較されます。（たとえば、反復可能なパフォーマンステストを使用して）のDECIMAL(9, 0)代わりに使用するとパフォーマンスが低下することを示すことができますINTか？

— -vstrien

私はできると思ったが、私のテストが決定的でないことを認める。おそらくSQLは、問題を整数演算に減らすための最適化を行っています。私のテストベッド： `--Int比較SET @StartTime = SYSDATETIME（）WHILE（@CounterINT <@SizeINT）SET @CounterINT = @CounterINT + 1 PRINT 'INT takes' + CONVERT（VARCHAR（20）、DATEDIFF（millisecond、@StartTime）、SYSDATETIME（）））+ 'milliseconds' --10進数のSET @StartTime = SYSDATETIME（）WHILE（@CounterDEC <@SizeDEC）SET @CounterDEC = @CounterDEC + 1 PRINT 'DEC takes' + CONVERT（VARCHAR（20）、DATEDIFF （ミリ秒、@StartTime、SYSDATETIME（）））+ 'ミリ' `

— クリス・チャブ

実際、SQL Serverは何かを最適化すると思います。最適化にDECIMALもかかわらず、通常は多少時間がかかります（少なくとも私の開発システムでは）。10のテストの実行では、DECが51ミリ秒、INTが46ミリ秒でした。

— -vstrien

ストレージスペースの面ではメリットがないようです。

クライアントが値が2 ^ 32-1（整数が保存できる正の最大値）よりも大きくなることを懸念している場合、BigIntへの移行を検討する必要があります-withは64ビット（8バイト）です。

— AlexTheDeveloper
ソース