データベースの日付時刻型に思うこと
MySQLもPostgreSQLもだけど、日付・時刻両方を格納するデータ型は、格納サイズとして8バイトが必要*1。
で、扱える範囲は、どちらも少なくとも西暦0年〜9999年までいけるので、まぁよっぽど古代の歴史に関することや、宇宙規模の事でない限りは、どんなApplicationでも問題無い。
ただ、ちょっと思うのは…
そもそも一般的なアプリケーションで、そこまでの日付範囲が必要なのはかなり稀なのでは？
例えば、あるデータの「登録日時」を格納するカラムがあったとして。
今から作るアプリケーションであれば、「今以前」の時刻って必要ないですよね、少なくともこのカラムに関しては。
で、アプリケーションの寿命次第ではあるけど、今から初めて、4バイトで表現できる経過秒数（およそ68年）を越えるアプリってそうそうないんじゃないかと。
なので、「エポック日時をデータ型指定時に指定できる日付時刻型」みたいのがあれば、4バイトの格納サイズで、実用的な日付時刻データを扱えるんじゃないかなぁ、とかちょっと思った。
4バイトくらいけちるなよ、と思うかもしれないけど、
ソーシャルゲームなんかで、データ件数1億件とかいくテーブルがあると、この1カラムあたり4バイトの差でも結構でかい*2。
まぁやろうと思えば、4バイト整数型で格納して自前で計算すればいいんだけど。
ただそうすると、生データを見た時に、ぱっと見がわかりにくいのと、ＤＢの日付時刻関数が使えない、というデメリットもあるわけで。
まぁ…そのデメリットと、データ領域圧縮のメリットの天秤なのかな…どっちとるかは。
