web-dev-qa-db-ja.com

SQL Server Decimal（9、0）対INT

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

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

DECIMALではなくINTを使用することの2つの「利点」を考えることができます。

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

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

  • 整数に位取りを追加しても、ごく一部の場合にのみ意味があります（位取りが違いをもたらすほとんどの場合、事前に追加することもできます）。
  • SQL Serverは、すべての精度とスケールの組み合わせを異なるデータ型として認識します。そのため、精度またはスケールを増やすときにデータ型がそのままにされることはありません。

これは私に不思議に思います：整数のDECIMAL(5,0)データ型の追加の利点は何ですか？

sql-servert-sqldatatypes
15
vstrien

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

処理に関しては、@ Andriyのように、DECIMALは、重要な場合、小数部分を失わないタイプに自然に分割されると述べています。

一方、多くのSUM（）または比較（値の検索など）をパイプライン処理するため、数値の観点から見ると、ネイティブINTタイプの処理はmuchより高速です。 CPUによって効率的に。 intの比較は2つのアセンブリオペコード（MOV、CMP）ですが、10進数の比較は非常に多くなります。

8
Chris Chubb

記憶域の点でメリットがないようです。

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

2
AlexTheDeveloper