日付を日付として格納しない利点は何か？
日付がシリアル値ではない数値や文字列として格納されていて困ったことはあるんだが、逆に得したことはない。にもかかわらず、（私が十数年で触れることのあった範囲で）２０％程度のデータ設計で日付が数値や文字列として格納されていることがある。
とりあえず、是非はおいといて、日付をシリアル値ではない数字列や文字列として格納してあると困ることを２〜３あげてみよう。もっと色々あると思うんですが、数字列や文字列で保存されていて得したことは１つも思い出せません。
不正な日付が格納できる
これは場合によっては必要要件になりうるのだが、日付＋状態といった２値に分割することもできるので設計次第なところはある。
特にひどいのは和暦形式で、0=明治以前、1=明治、2=大正、3=昭和、4=平成みたいなやつ。4010105（平成元年１月５日）と 3640107（昭和６４年１月７日）とか、前者を不正な日付としてはじけるのか？受け入れるならソートはどうするのか？といった問題まで持っていたりします。
年度制のシステムで４月〜３月を４〜１５で表現されているものも類似だが、この場合は「月コード」みたいな形で独立して保存されていることが多いので除外してもよさそうかな？
演算しにくい
格納形式が日付ではないデータに対しては、データベースの持つ日付演算機能が使えなくなるのは痛いです。３日後の日付を取得するとか、日付間の日数を計算するとか月末を取得するとかそういうやつですね。データベースにもよりますが、単純に月を１足すだけではなく、当月末を翌月末に加算するような＋１ヶ月の演算もサポートしていることもあります。
結局のところ、日付に変換→演算→数字列や文字列に変換 という手順を踏んでしまったりすることになります。
読み書きしにくい
日付データを読み書きできない API しか持たないデータベースはほとんどなくて、直接利用する場合でもミドルウェアやライブラリ類を使う場合にも、日付型で保存されていれば日付として読み書きできることがほとんどです。しかし、数字列や文字列として格納されている場合はどこかで変換しなければなりません。
SQL 側で SELECT/INSERT にて SQL 文で日付と相互変換する場合、つまり利用側からみて日付として扱うような場合は、最初から日付で格納してればいいですよね…。そんなこともあって、数字列や文字列として格納されているような場合に、日付への変換は利用側で行われていることが多いように思います。
それで……自分のまわりだけとは思いたくないんですが……この日付と文字列の変換がきちんとできない人が結構多いんですよね。専用のユーティリティがあるわけでもなく、独自の変換ユーティリティを作成しているシステムもありますが、多くのシステムで「単純な変換だ」と使う場所場所に変換処理が散在していることが多いです。そして、そこらじゅうに不具合が埋め込まれてどうにもならない、と。
最近の弊社別支店からあがってきた C# での実装でも、年月日が横に並んだ数値列型のデータを格納するのに、
ExecuteSQL("INSERT INTO table1 (numeric_date_column) VALUES (:now)", new { now = DateTime.Today.ToString("yyyyMMdd"), });
みたいな間違った実装がありました。ストアドで投入する側にはこんな不具合がなく、当然のように読みだす側にもおなじ不具合があったりして、即時処理で画面から登録したデータと一括処理でストアドから登録したデータの格納形式が違っていたり、画面表示が狂ったりとすごいことになっていました。
