ありがとう。また会おう。

まぁゆるりとやっていきますよと。

データベースの日付時刻型に思うこと

MySQLPostgreSQLもだけど、日付・時刻両方を格納するデータ型は、格納サイズとして8バイトが必要*1
で、扱える範囲は、どちらも少なくとも西暦0年〜9999年までいけるので、まぁよっぽど古代の歴史に関することや、宇宙規模の事でない限りは、どんなApplicationでも問題無い。

ただ、ちょっと思うのは…
そもそも一般的なアプリケーションで、そこまでの日付範囲が必要なのはかなり稀なのでは?

例えば、あるデータの「登録日時」を格納するカラムがあったとして。
今から作るアプリケーションであれば、「今以前」の時刻って必要ないですよね、少なくともこのカラムに関しては。
で、アプリケーションの寿命次第ではあるけど、今から初めて、4バイトで表現できる経過秒数(およそ68年)を越えるアプリってそうそうないんじゃないかと。

なので、「エポック日時をデータ型指定時に指定できる日付時刻型」みたいのがあれば、4バイトの格納サイズで、実用的な日付時刻データを扱えるんじゃないかなぁ、とかちょっと思った。

4バイトくらいけちるなよ、と思うかもしれないけど、
ソーシャルゲームなんかで、データ件数1億件とかいくテーブルがあると、この1カラムあたり4バイトの差でも結構でかい*2

まぁやろうと思えば、4バイト整数型で格納して自前で計算すればいいんだけど。
ただそうすると、生データを見た時に、ぱっと見がわかりにくいのと、DBの日付時刻関数が使えない、というデメリットもあるわけで。

まぁ…そのデメリットと、データ領域圧縮のメリットの天秤なのかな…どっちとるかは。

*1:MySQLには、4バイトのtimetamp型があるけど、これは副作用もあって扱いにくいのでここでは除外

*2:ディスク領域的にはそれほどでもないけど、メモリにデータを載せきることまで考えると