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

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データではむしろそこが主眼になり得るからです。