SQLite: 欠陥デフォルトを修正するための「エディション」案

SQLite はローカルデータストアの業界標準であり、多数の組み込みプロジェクトやサーバーソフトウェア（lobste.rs など）で採用されています。従来の RDBMS と異なり独立したプロセスではなくライブラリとして動作し、ファイル形式も独自です。これにより完結したシステムかつシリアライザー不要という「両方の世界の良さ」を実現します。

しかし、この素晴らしいデータベースには致命的なデフォルト設定が多数存在します。本記事ではその問題点と、Rust のエディション制度を参考にした解決策（Super PRAGMA）を提案します。

欠陥デフォルト #1: 外キー制約の無視

SQLite は当初、外キー制約をデフォルトで無効にします。これによりデータベースの整合性が失われ、ダングリングリファレンス（参照先のないリンク）が許容されます。さらに悪化するのは、

INTEGER PRIMARY KEY

（ROWID）が再利用されることがあり、削除された行の ID を別の行が占有することで、エラーにならずにデータが汚染されてしまう点です。

問題事例

以下のシナリオを想定します。

ユーザー「Bob」を作成し、投稿を残す。
ユーザー「Bob」を削除する（外キー制約違反のエラーが発生しない）。
新しいユーザー「Alice」を作成する（Bob の旧 ROWID が再利用される）。
Alice が Bob の古い投稿を引き継いでしまう（
```
FOREIGN KEY(user_id) REFERENCES users(id)
```
を無視するため）。

-- Bob 作成
INSERT INTO users (display_name) VALUES ('Bob'); 
-- id = 1

-- 投稿作成 (Bob の ID=1 を参照)
INSERT INTO posts (user_id, content) VALUES (1, 'Hello, I am Bob'); 

-- Bob 削除 (エラーなし: 制約無効のため)
DELETE FROM users WHERE id = 1; 

-- Alice 作成 (ROWID アルゴリズムにより id=1 が割り当てられる)
INSERT INTO users (display_name) VALUES ('Alice');

-- 結果: Alice の名前で Bob の投稿が閲覧できてしまう！
SELECT u.display_name, p.content 
FROM users as u, posts as p 
WHERE u.id = p.user_id;

修正方法

SQL 実行直前に以下のコマンドを実行し、制約を有効化します。

PRAGMA foreign_keys = ON;

これにより、ユーザー削除時に

FOREIGN KEY constraint failed

エラーが適切に発生するようになります。

欠陥デフォルト #2: 動的な型アフィニティによるデータ汚染

SQLite は簡素な型システムを持ちますが、非厳密モードでは宣言された型よりも挿入時の値の形式（アフィニティ）を優先します。例えば

INTEGER

列に文字列

'321'

を入れると整数として保存され、無理な文字列

'TooLong'

を入れようとしてもエラーにならずそのまま保存されてしまいます。

型変換のルール（非厳密モード）

宣言された型	許容される挿入値の変換挙動
INTEGER	`TEXT` / `REAL` は数値に変換され、適正でない文字列はそのまま保存。
TEXT	`BLOB` はそのまま、 `TEXT` はそのまま、数値は `TEXT` へ変換。
REAL	`INTEGER` は `REAL` へ変換、適正でない数値は整数保持。
BLOB	基本的に何でもそのまま保存（二進データ以外の文字列も）。

これにより、「ブール値として 0/1 を期待」する場所に

'1'

という文字列が残り、バグの原因になります。

修正方法：厳密テーブル (Strict Tables)

SQLite には厳密モードという概念があります。これを有効にすると、型不一致時に即時エラーを返します。

CREATE TABLE music (
    id INTEGER PRIMARY KEY,
    name TEXT,
    duration_sec INTEGER -- デフォルトでは型変換が許容される
) STRICT; -- 厳密モード設定により型チェックが強制される

INSERT INTO music (name, duration_sec) 
VALUES ('The Way of All Flesh', 'Way too long'); 
-- エラー: INTEGER 列に TEXT 値を保存できない

※ グローバルな設定はないため、各テーブル定義時に

STRICT

を追加する必要があります。

補足: 型アライアス（例：
CREATE TYPE KEY_VALUE_SET = TEXT;
）や制約付き領域の導入も検討されていますが、現状では手動での
STRICT
指定が現実的です。

欠陥デフォルト #3: 並行書き込み時の SQLITE_BUSY エラー

SQLite は同時読み込みを許しますが、同時書き込みは禁止されます（互斥ロック）。デフォルト設定では、別のプロセスが書き込み中の場合に

SQLITE_BUSY

エラーを即座に返します。これは長時間の I/O 中にソフトウェアをクラッシュさせる不安定な挙動です。

修正方法：待機時間の延長

書き込みロック取得を試行し、失敗するまで一定時間待つ設定を行います。

PRAGMA busy_timeout = 5000; -- 最大 5 秒間待機

これにより、一時的な競合は自動的に解消され、システムが不安定になるのを防ぎます。

補足: すべての書き込みを単一のスレッドで行う設計がベストですが、CLI ツールやシェルスクリプトなど多様なユースケースに対応するためには、この待機時間の設定が不可欠です。

欠陥デフォルト #4: パフォーマンスとデータ安全性

サーバー環境において SQLite が最大のパフォーマンスを発揮できない主な要因は、以下の 2 つの無効な設定です。

設定項目	デフォルト値	推奨値	メリット
WAL (Write-Ahead Log)	`OFF` (delete)	`WAL`	読み書きの並行性向上、停止時間の減少。劇的な書き込み速度改善。
Synchronous	`FULL` (最安全だが重い)	`NORMAL`	データ破損リスクは許容範囲内でありつつ、ディスク同期回数を削減しパフォーマンス向上。

設定コマンド

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

Sylvain Kerkour の記事 [Optimizing SQLite for servers] も参考推荐阅读です。

解決策: 「スーパー PRAGMA」によるエディション化

上記の問題はすべて、後方互換性の確保と「アップグレードによる既存データの破損」を恐れる心理から残されています。依存関係を壊さず、合理的なデフォルトを適用する手段として、

PRAGMA edition

の導入を提案します。

提案案：2026 エディション

以下のコマンドを実行することで、複数の設定が一括で有効化されます。

PRAGMA edition = 2026;

内部的に展開する Pragmas

この命令は以下の設定の組み合わせとして機能します。

```
PRAGMA foreign_keys = ON;
```
```
PRAGMA busy_timeout = 5000;
```
```
PRAGMA journal_mode = WAL;
```
```
PRAGMA synchronous = NORMAL;
```

追加推奨：テーブルのデフォルト厳密化

データベースエンジンの進化に合わせて、新たなデフォルトを採用しつつ旧互換性を保つための折衷策として、各テーブルで

STRICT

を明示するか、エディションによるデフォルト挙動の変更も検討可能です。

エディション制度の利点

Rust のエディション概念: 時間を基準にした合理的なデフォルト変更が可能になります（例：将来的に WAL2 が標準になる場合、
```
edition = 2034
```
で対応）。
JavaScript の
use strict
との違い: システム全体の安全水準を段階的に引き上げることができます。

SQLite は、時代遅れのデフォルト値から解放された**「アップ・トゥ・デート」**のエディションシステムを持つべきです。

SQLite に（Rust のような）エディション導入が必要です。

日本語訳: