随時翻訳を続けています。
Distinctive Features Of SQLite
このページは、独特な、そして SQLite を他の多くの SQL データベースエンジンと区分けする SQLite のいくつかの特性にハイライトを当てます。
設定無し
SQLite は、使う前に「インストール」する必要がありません。 「セットアップ」手順がありません。 開始、停止、そして設定する必要があるサーバープロセスがありません。 管理者が新しいデータベースのインスタンスを作成したり、あるいはユーザーにアクセス許可を割り当てる必要がありません。 SQLite は環境設定ファイルを使いません。 SQLite をシステムで走らせるために何もする必要がありません。 システムクラッシュあるいは停電の後、回復のための作業を必要としません。 トラブルシューティングは必要ありません。
SQLite は何もしなくても機能します。
あなたがそれらを完全にこなすなら、他のよく知られるデータベースエンジンのほうがうまく稼働します。 しかし、インストールと初期設定が、恐ろしいほど複雑になり得ます。
サーバーレス
ほとんどの SQL データベースエンジンは、分離したサーバープロセスとして実装されています。 データベースにアクセスしたいプログラムは、何らかのプロセス間通信（典型的には TCP/IP）を使うサーバーにリクエストを送り、戻ってくる結果を受け取ります。 SQLite はこのように機能しません。 SQLite では、データベースにアクセスしたいプロセスはディスク上のデーターベースファイルから直接読み書きします。 仲介するサーバープロセスは無いのです。サーバーレスということには、有利な点と不利な点があります。 主な利点は、インストール、セットアップ、設定、初期化、管理、そしてトラブルシュートを必要とする分離したサーバープロセスが無いということです。 SQLite がなぜ「設定不要」データベースエンジンであるかという理由のひとつはこれです。 SQLite を使うプログラムが実行される前に、データベースエンジンをセットアップするための管理者のサポートを必要としません。 ディスクアクセスが可能などんなプログラムでも SQLite データベースを使うことができます。
一方、サーバーを使うデータベースエンジンは、クライアントアプリケーションのバグからもっと良く保護できます。 （クライアントの逸脱したポインタがサーバーのメモリを破壊することは不可能です。） そしてサーバーが単独の永続的なプロセスであるため、よりきめ細かなロックとより良い並行処理を可能にし、高精度なデータベースアクセス制御を可能にします。
ほとんどの SQL データベースエンジンは、 C/S ベースです。 サーバーレスデータベースエンジンで、ひとつのデータベースに同時に複数のアプリケーションからアクセスできるものは、 SQLite 以外著者は知りません。
データーベースファイルひとつだけ
SQLite データベースは、ディレクトリ階層のどこにも位置できる単独の一般的なディスクファイルです。 SQLite がディスクファイルを読めるなら、データベース内のすべてを読むことができます。 ディスクファイルとディレクトリが書き込みできるなら、 SQLite はデータベース内のすべてを変更できます。 データベースファイルは容易に USB メモリスティックにコピーしたり電子メールで共有したりできます。他の SQL データベースエンジンは、ファイルの大きな山としてデータを保存する傾向があります。 たいていこれらのファイルは、データベースエンジン自身だけがアクセスできる標準の場所にあります。 これはデータをより安全にしますが、同様にアクセスをさらに難しくします。 いくらかの SQL データベースエンジンは、ファイルシステムをまとめて回避し直接ディスクに書き込むオプションを備えています。 これは、かなりの設定と複雑な管理という犠牲の上に、更なる性能を提供します。
コンパクト
サイズ優先で最適化された場合、 SQLite ライブラリ全体で（ＧＮＵコンパイラスイートの「 size 」ユーティリティーを使って ix86 上で測定されるように）、すべて使用可能な状態で225KB 以下の大きさしかありません。 望むなら、いらない機能をコンパイル時に使用しない設定として、ライブラリの大きさを 170KB 以下に下げることもできます。たいていの他の SQL データベースエンジンは、もっともっと大きいです。 最近リリースされた CloudScape データベースエンジンは、「たった」 2MB しかない jar ファイルだと IBM は豪語しますが、圧縮した後でさえ SQLite より 10 倍も大きいのです！ Firefox は、クライアント側ライブラリがたった 350KB に過ぎないと自慢しています。 それは SQLite より 50% も大きく、データベースエンジンを含みさえしません。 Sleepycat によるバークレー DB ライブラリは、 450KB ですが、単純なキー/値の組をプログラマーに提供するのみで SQL サポートはありません。
Manifest typing
たいていの SQL データベースエンジンは、静的な型付けを使います。 データ型はテーブルのそれぞれのカラムと結び付けられ、そしてその特定のデータ型の値だけがカラムに保存できます。 明確な型付けを使うことで、 SQLite はこの制限を緩和します。 明確な型付けでは、データ型は値が保存されるカラムではなく、値自身の属性です。 従って SQLite は、そのカラムで宣言された型にかかわらず、どんなデータ型でもどんな値でも、いずれのカラムの中にも保存することができます。 （この規則には若干の例外があります。INTEGER PRIMARY KEY カラムは、整数のみ保管します。 そして可能なら、 SQLite は値をカラムで宣言されたデータ型に強制しようと試みます。）SQL 言語仕様は静的な型付けを要求します。 そのため、いくらかの人々は、明確な型付けを使うことは SQLite のバグだと感じます。しかし、SQLite の著者は、これは特徴なのだと非常に強く感じます。 著者は、（ SQLite が後方互換性を維持したまま修正した） SQL 仕様のほうがバグなのだと主張します。
可変長レコード
たいていの他の SQL データベースエンジンは、たいていのテーブルで各行に固定量のディスクスペースを割り当てます。 それらは、乱暴に長さを変えることがあり得る BLOB と CLOB を扱う場合、特別なトリックを使います。 しかし、たいていのテーブルで、あなたがカラムを VARCHAR(100) と宣言した場合、実際にどれぐらいの情報をカラムに保存するかにかかわらず、データベースエンジンは 100 バイトのディスクスペースを割り当てるでしょう。対照的に SQLite は、行に情報を保存するために、実際に必要なディスクスペース量だけを使います。 あなたが文字ひとつを VARCHAR(100) カラムに保存するなら、ただ 1 バイトのディスクスペースだけ消費します。 （各カラムの最初にデータ型とデータ長を記録する若干のオーバーヘッドがあるので、実際には 2 バイトです。）
SQLite の可変長レコードの使用は多くの利点があります。 それは明らかに、データベースファイルを小さくします。 同様に、ディスクから動かす情報を小さくするということですから、データベースはより高速に動きます。 そして可変長レコードを使うことで SQLite は、静的な型付けに代わって明確な型付けを用いることができるようになります。
読みやすいソースコード
SQLite のソースコードは読みやすく平均的なプログラマーにとって理解しやすいよう設計されています。 プロシージャとデータ構造と多くの自動変数に、それらが何をするかについての役立つ情報とともに注意深くコメントをつけました。 決まりきったコメント付けは省略しました。
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 を定義します。