読者です 読者をやめる 読者になる 読者になる

DPCデータの分析とかやるブログ

DPCデータの分析なんかをテキトーにやってます。

SQLiteと日付型データについて

SQL

SQLiteは素晴らしいツールです。
単体exeで走り、かつデータベースは一つのファイルに纏まるので、DBをUSBに入れて、実行環境ごと持ち運ぶことが出来ます。
パブリックドメインなので、好きなように使って大丈夫です。Accessと違って、DBのサイズ制限も無いようなもんです。
ここまで書けば、結論は確かですね。最初のDBはSQLiteを使いましょう!

が、このブログではそうしてません。何故でしょうか。

日付型データの問題

SQLiteは基本的に、整数・浮動小数・テキスト、の三種類のデータを扱えます。
何か足りない気がしますね。
そう、日付型です。
日付型がないのはそんなに問題でしょうか? はい、とんでもない問題になります。 例えば

20161231 - 20161201 = 30ですが、

20170101 - 20161231 = 8870になります。

この結果を期待する人はいませんね。 これは致命的な欠点に思えますし、実際ひどいのですが、回避策は(なんと!)あります。
julianday関数です。 データをユリウス通日に変換することで、日付のように振る舞う数字データを入手できます。
やりましたね!

…いえいえ、ちょっと待ってください。ユリウス通日?一体何のことでしょう?
Wikipediaの記載によれば、

ユリウス通日(ユリウスつうじつ、Julian Day、JD)とは、ユリウス暦[注 1]紀元前4713年1月1日(すなわち西暦-4712年1月1日)の正午(世界時)からの日数である[1]。単にユリウス日(ユリウスび)ともいう

だそうです。つまり、その日が紀元前4713年1月1日から、通算して何日目なのかを、「数字として」返す関数だ、ということです。 そりゃまあ、これを使って変換すれば、あとは数字の引き算ですから、

select julianday("2017-01-01") - julianday("2016-12-31")

は、1.0を返します。でも、全ての日付処理をこうやって変換するのは、あまりいいアイディアではありませんね。
というわけで、個人的には初めてのSQLはPostgres辺りをお勧めしています。
日付型データを扱う必要が無ければ、SQLiteでもいいんですが、DPCデータではむしろそこが主眼になり得るからです。