SQL Serverで年月カラムを定義する際についてのメモを、個人的な備忘録として残しておこうと思います。
今回の記事を書こうと思った出来事について
ある案件で、SQL Serverを使用しているシステムで年月を管理するテーブルがありました。
このテーブルでは、処理したタイミングの年月を抽出して「処理年」、「処理月」といった形でカラムを定義していました。
それぞれ、各カラムは以下のように定義していました。
- 「処理年」
カラム名：「ProcessYear」
データ型：「decimal(4, 0)」
- 「処理月」
カラム名：「ProcessMonth」
データ型：「decimal(2, 0)」
本来ならば、整数の値のみを取りうる「年」と「月」に、decimal型を使用しているのにとても違和感を覚えました。
今回は、このシステムのように年月を別々にカラム定義して保持するケースにおいて、他の例ではどのように定義しているのかを簡単に調査したメモです。
SQL Serverのサンプルデータベースはどうしているか？
SQL Serverはサンプルデータベースを提供しているので、そのなかで年月カラムを保持しているテーブルを調べてみました。データベース名は、「AdventureWorks2016」です。
その中に似たようなカラム定義をしているテーブルを見つけました。
「Sales.CreditCard」テーブルです（クレジットカードを保持するテーブルのようですね）。
上記の通り、以下のようにカラムを定義していました。
- 「ExpYear」（有効期限、年）※クレジットカードの有効年
データ型：「smallint」
- 「ExpMonth」（有効期限、月）※クレジットカードの有効月
データ型：「tinyint」
なるほど、整数型をそれぞれ使っていて取りうる値に応じて適切なデータ型を選択しているということが分かりました。
データ型によるストレージ容量について
decimal型と、smallint型、tinyint型をそれぞれ使った場合のストレージ容量を調べてみました。公式サイトを参考にしたところ、以下の通りでした。
| データ型 | ストレージ(Byte) | 備考 |
|---|---|---|
| decimal | 5 | 定義によるが今回のケースではこの容量となる |
| smallint | 2 | |
| tinyint | 1 |
decimal型は、小数点以下を扱うことができるデータ型のため少し容量を多く使うようです。ストレージで見た場合には、decimal型ではなく年月それぞれで適切な整数のデータ型を使用する方がより望ましいと思われます。
調べてみて
年月カラムは結論としては、サンプルデータベースのように適切な数値型を使用する方が良さそうです。
整数しかとりうる値がない場合は、意図も含めて整数型で定義すべきに思えます。
整数しかとりうる値がないのに「decimal(4, 0)」という定義をしている場合、何か意味があるのかと使用する人を惑わせることになるので、不要な混乱を避けるためにも、正しいデータ型を選択したいと思います。
経験や知識がないだけなのかもしれませんが、現時点で調べた感じだとこのような結論になりそうです。
また、上記では触れませんでしたがデータ型を大きく定義してしまうことにより、アプリケーションのパフォーマンスにも影響が発生するなどの記事もいくつか見かけました。実際に試してないので、確証はないですが無駄な領域を定義することにより、メモリもその分使ってしまい遅くなるのは容易に想像できるので、なんとなく正しい意見のような気がします。
今回はこの辺で失礼いたします。最後までお読みいただきありがとうございました。
