どんなときに使うと効果的か？
対象環境
情報源
特徴
- ゼロ構成
- サーバーレス
- 単一データベースファイル
- 安定したクロスプラットフォームデータベースファイル
- コンパクト
- マニフェストタイピング
- 可変長レコード
- 読みやすいソースコード
- SQL文は仮想マシンコードにコンパイルされる
- パブリックドメイン
- SQL言語の拡張
抜き出し
ゼロ構成
インストール、設定不要。
というけど、ビルドツールをインストールせねばSQLite3バイナリを作れないのでは？ かつて私がやったログは以下。
サーバーレス
サーバプロセスによる手間が不要なのはステキ。でも、自前で排他制御せねばならないのは面倒。
安定したクロスプラットフォームデータベースファイル
すべてのマシンで同じファイルフォーマットを使用できる。ビッグエンディアン・リトルエンディアン、32・64ビットだろうが関係ない。
コンパクト
ライブラリのサイズは500KBとある。
でも、前に私がSQLite3 3.22.0のバイナリをビルドしたときは4MBになったよ？ いくつかオプションつけたけど。ライブラリより実行バイナリを使うだろうから、そのサイズを書いて欲しい。
マニフェストタイピング
数値だろうがテキストとして保存しちゃう。日付型なんてない。テキストで保存。それを「マニフェスト型」と呼ぶようだ。
TclやPythonなどの動的に型付けされたプログラミング言語と組み合わせて使用する場合に、SQLiteの信頼性と使いやすさを実際に証明する意図的な設計上の決定です。
ということで、静的型付プログラミング言語のことは考慮されていない。自前でマッピングせねばならない。別途ORマッパーを使って簡略化するのが一般的。
可変長レコード
ほとんどのDBは文字列をVARCHAR(100)のように固定長で宣言する。たとえその長さがなくとも100バイトのディスクスペースを割り当てる。これに対してSQLiteは実際に必要なスペースだけ割り当てる。
ファイルサイズが小さくなるのはわかる。でも、実行速度が高速になるって本当か？ 固定長のほうが速いのでは？ 全レコードにおいて開始と終了の位置が一度で計算できるからレコードごとのポインタ計算が不要になる。逆に可変長はそれが必要だから、その分遅くなると思うのだが。いや、実装を知らんので分からんが。
読みやすいソースコード
パブリックドメイン
すばらしい。
SQL言語の拡張
いつかやってみたい。でもC言語。
ファイルシステムとかネットワーク上のAPIやコンテンツをSQLで操作できたらいいのに。
