SQLite の顕著な特徴

以下は、 ２０１６年１２月現在の sqlite 文書、Distinctive Features Of SQLite 、SQLite の顕著な特徴、の、kanda.motohiro@gmail.com による訳です。以下の条件で、公開します。

The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law.

このページは、SQLite の特徴のいくつかをハイライトします。それらは普通とは違い、SQLite を多くの他の SQL データベースエンジンと区別するものです。

ゼロ設定

SQLite は、使うために「インストール」する必要がありません。「設定」手続きはありません。開始、終了、あるいは設定する必要のあるサーバプロセスはありません。管理者が新しいデータベースインスタンスを作成したり、ユーザにアクセス権限を与える必要はありません。SQLite は、設定ファイルを使いません。システムに、SQLite が動いていることを伝えるために何もする必要はありません。システムクラッシュや電源障害の後に、回復のために必要な動作はいりません。トラブルシュートすべきものは何もありません。

SQLite は、ただ、動きます。

より著名な他のデータベースエンジンは、一度、動かすことができれば、素晴らしく動きます。しかし、最初のインストールと設定はおそろしく複雑なことがあります。

サーバレス

ほとんどの SQL データベースエンジンは独立したサーバプロセスとして実装されています。データベースをアクセスしたいプログラムは、サーバに要求を送って、結果を受け取るために、なんらかの種類のプロセス間通信（典型的には TCP/IP）を使って、サーバと通信します。SQLite はこのようには動きません。SQLite の場合は、データベースをアクセスしたいプロセスは、ディスク上のデータベースファイルを直接、読んで、書きます。中継するサーバプロセスはいません。

サーバレスであることには、利点と欠点があります。主な利点は、インストール、設定、構成、初期化、管理、そしてトラブルシュートするべき独立したサーバプロセスがいないことです。これは、SQLite が「ゼロ設定」のデータベースエンジンである一つの理由です。SQLite を使うプログラムは、それを動かす前に、データベースエンジンを設定する管理的サポートがいりません。ディスクをアクセスできるプログラムならどれでも、SQLite データベースを使うことができます。

一方、サーバを使うデータベースエンジンは、クライアントアプリケーションのバグに対して、より良い保護を提供できることがあります。クライアントのこわれたポインタは、サーバのメモリをこわすことはできませんから。そして、サーバが単一の永続的プロセスであるために、データベースアクセスをより高い精度で制御することができます。それは、より細かい粒度のロックとより良い同時実行性を可能とします。

ほとんどの SQL データベースはクライアント／サーバを基本とします。サーバレスであるものの中で、著者が知る限り、SQLite だけが、複数のアプリケーションが同じデータベースを同時にアクセスすることを許します。

単一のデータベースファイル

SQLite データベースは、単一の普通のディスクファイルで、ディレクトリ階層のどこに置いてもかまいません。SQLite がそのディスクファイルを読むことができれば、それは、そのデータベースの全てを読むことができます。もしそのディスクファイルとそのディレクトリが書き込み可能ならば、SQLite はそのデータベースで何でも変更できます。データベースファイルは、簡単に USB メモリスティックにコピーしたり、電子メールで共用できます。

他の SQL データベースエンジンは、データを大量のファイルの集まりとして格納することが多いようです。これらのファイルはしばしばそのデータベースエンジンだけがアクセスできる標準の場所にあります。これはデータをよりセキュアにします。しかし、アクセスを難しくもします。SQL データベースエンジンによっては、ファイルシステムを全くバイパスして、直接ディスクに書くオプションを提供するものがあります。これは性能を上げますが、設定とメンテナンスのかなりの複雑さという犠牲を払います。

安定したクロスプラットフォームのデータベースファイル

SQLite のファイル形式はクロスプラットフォームです。あるマシンで書かれたデータベースファイルは、異なるアーキテクチャの別のマシンに複写して、使うことができます。ビッグエンディアンあるいはリトルエンディアン、３２ビットあるいは６４ビット、は関係ありません。すべてのマシンは同じファイル形式を使います。さらに、開発者たちはこのファイル形式を、安定し、後方互換性を持つように維持することを誓いました。なので、SQLite のより新しいバージョンは、より古いデータベースファイルを読んで書くことができます。

他のほとんどの SQL データベースエンジンは、あるプラットフォームから別のにデータベースを移動したり、ソフトウェアのより新しいバージョンにアップグレードするときにしばしば、データベースをダンプして回復する必要があります。

コンパクト

大きさを最適化したとき、全てを有効にした SQLite ライブラリ全体は、500KiB 以下の大きさ です。（ix86 で、 GNU コンパイラスイートの "size" ユーティリティを使って測りました。）もしお望みならば、コンパイル時に不必要な機能を無効にして、ライブラリの大きさを、さらに小さく、300KiB 以下にすることもできます。

他のほとんどの SQL データベースエンジンは、これよりもずっと大きいです。IBM は、それが最近リリースした CloudScape データベースエンジンが、「たった」 2MiB jar ファイルであると自慢しています。圧縮した後でも、これは、SQLite よりも一桁大きいです！Firebird は、そのクライアント側のライブラリがたった 350KiB であると自慢しています。それはSQLite と同じくらい大きく、データベースエンジンは全く含んでいません。Oracle による Berkeley DB ライブラリは、450KiB であり、SQL サポートはついていません。プログラマには、単純なキーと値の対だけを提供します。

マニフェスト型付け

ほとんどの SQL データベースエンジンは静的な型付けを使います。テーブルのそれぞれのカラムには、データ型が関連付けられ、その特定のデータ型を持つ値だけが、そのカラムに格納されることができます。SQLite は、マニフェスト型付けを使って、この制限をゆるめます。マニフェスト型付けでは、データ型は、値自身の属性です。その値が格納されるカラムの属性ではありません。なので、SQLite は、ユーザが、いかなるデータ型のいかなる値も、任意のカラムに格納することを許します。そのカラムの宣言された型は無関係です。（この規則にいくつかの例外があります。INTEGER PRIMARY KEY カラムは、整数しか格納できません。また、SQLite は、可能であれば、値を、そのカラムの宣言されたデータ型にあてはめようとします。）

私の知る限り、SQL 言語仕様はマニフェスト型付けの使用を許します。しかし、他のほとんどの SQL データベースエンジンは、静的に型付けされているので、ある人々はマニフェスト型付けを使うのは SQLite のバグであると感じます。しかし、SQLite の作者たちは、これが機能であるととても強く感じます。SQLite がマニフェスト型付けを使うのは、考え抜かれた設計上の選択です。それは、現実に、SQLite をより安定し、使いやすくするためにはたらいてきました。それは特に、Tcl や Python のように、ダイナミックに型付けされるプログラム言語と一緒に使われるときに顕著です。

可変長のレコード

他のほとんどの SQL データベースエンジンは、ほとんどのテーブルのそれぞれの行に、固定長のディスク領域を確保します。BLOB と CLOB のように、大きく長さが変わるものを扱うときには、特別のトリックを使います。しかし、ほとんどのテーブルにおいて、もしあなたがあるカラムを VARCHAR(100) と宣言したら、データベースエンジンは、そのカラムにあなたが実際にどれだけの大きさの情報を格納するかには無関係に、１００バイトのディスク領域を確保するでしょう。

それに対して、SQLite は、行にある情報を格納するために実際に必要なディスク領域だけを使います。あなたが VARCHAR(100) カラムに、たった一文字を格納したら、１バイトのディスク領域だけが使われます、（実際は、２バイトです。それぞれのカラムの先頭には、そのデータ型と長さを記録するためのオーバーヘッドが少しあります。）

SQLite が可変長レコードを使うのは、いくつかの利点があります。もちろん、より小さいデータベースファイルになります。また、ディスクから読んだり書いたりする情報が少ないために、データベースはより速く動きます。そして、可変長レコードのために、SQLite は、静的型付けでなく、マニフェスト型付けを使うことが可能となります。

読むことのできるソースコード

SQLite のソースコードは、平均的プログラマが読むことができ、アクセス可能なように設計されています。全ての手続きとデータ構造、そして多くの automatic 変数は注意深くコメントされており、それらが何をするかについて、有益な情報を提供します。無味乾燥なコメントは避けられています。

SQL 文は仮想マシンコードにコンパイルされます

全ての SQL データベースエンジンは、それぞれの SQL 文をなんらかの内部的データ構造にコンパイルします。それが次に、その文の仕事を行うために使われます。しかし、ほとんどの SQL エンジンでは、その内部的データ構造は、構造体とオブジェクトの複雑な網の目です。SQLite では、文のコンパイルされた形式は機械語のような表現を持つ短いプログラムです。データベースのユーザは、この仮想マシン言語を、問い合わせに EXPLAIN キーワードを加えることで見ることができます。

SQLite で仮想マシンを使うのは、ライブラリの開発にとって大いに助けとなりました。仮想マシンは、SQLite のフロントエンド（SQL 文を解析して、仮想マシンコードを生成する部分）と、バックエンド（仮想マシンコードを実行して、結果を計算する部分）との間に、鮮明でよく定義された接続を提供します。仮想マシンは開発者が、SQLite がコンパイルするそれぞれの文で、何をしようとしているかを、明確で簡単に読める形式で見ることを可能とします。それは、デバッグにとても役に立ちます。SQLite のコンパイルの仕方によって、それは、仮想マシンの実行を追跡する能力もあります。それぞれの仮想マシン命令とその結果を、実行するたびに表示します。

パブリックドメイン

SQLite のソースコードはパブリックドメインにあります。コアソースコードのいかなる部分についても、著作権の主張はされません。（文書とテストコードは違います。ある文書の節とテスト論理は、オープンソースライセンスに従います。）SQLite のコアソフトウエアへの全ての貢献者は、そのコードへの全ての著作権への関心を明確に拒否する宣誓供述書に署名しました。これは、誰でも、合法的に、SQLite ソースコードを使って、自分の望むことを何でもできることを意味します。

コードを広く、フリーに使うことを許す自由なライセンスを持つ SQL データベースエンジンは他にもあります。しかしこれら他のエンジンはまだ、著作権に縛られています。SQLite は、著作権が単純に適用されないという点で異なります。

他の SQL データベースエンジンのソースコードファイルは、典型的には、あなたがそのファイルを見て、複写してもよい法的権利を記述するコメントで始まります。SQLite のソースコードは、ライセンスを含みません。それは著作権で縛られないからです。ライセンスの代わりに、SQLite ソースコードは、祝福を与えます。

あなたが善をなし、悪をなさないように。

あなたがご自分を許し、他の人を許すように。

あなたが自由に共有し、与える以上のものを取らないように。

SQL 言語拡張

SQLite は、他のデータベースエンジンでは通常は見られない多くの SQL 言語拡張を提供します。EXPLAIN キーワードと、マニフェスト型付けは、既に述べました。SQLite は、REPLACE のような文を提供します。また、ON CONFLICT 節は、制約の競合を解決するときに、さらに制御を加えることができます。SQLite は、ATTACH と DETACH コマンドをサポートし、同じ問い合わせ中で、複数の独立したデータベースを一緒に使えるようにします。そして、SQLite は、ユーザが、新しい SQL 関数 と 照会シーケンスを追加するための API を定義します。

以上