SQLiteにRustスタイルのエディション導入を提案、デフォルト設定の改善を検討
SQLiteの問題のあるデフォルト設定を改善するため、Rustの手法に倣ったエディションシステムの導入が提案されている。同システムは外部キー制約や並行書き込みなどの複数の課題に対応し、後方互換性を保ちながら問題を解決するとみられる。
SQLiteは軽量で広く使われているライブラリベースのRDBMSだが、いくつかのデフォルト設定が問題のあるものとなっているという指摘がある。筆者は、外部キー制約がデフォルトで無視される、列に不正なデータ型が格納される、並行書き込み時に即座にSQLITE_BUSYエラーが発生する、パフォーマンスのデフォルト値が最適でない、といった4つの主要な課題を挙げている。
提案されるエディションシステムの内容
筆者はRustのエディション概念を参考に、SQLiteにも同様のシステムを導入することを提案している。提案では、PRAGMA edition = 2026 により、以下の設定がまとめて適用されるべきだとしている：
- PRAGMA foreign_keys = ON
- PRAGMA busy_timeout = 5000
- PRAGMA journal_mode = WAL
- PRAGMA synchronous = NORMAL
- テーブルのストリクトモードをデフォルトとする
各設定が対処する課題
SQLiteではデフォルトで外部キー制約が無視されるため、データ整合性の問題が生じやすい。また、非ストリクトモードのテーブルでは列に不正なデータ型を格納することが可能であり、筆者は実際にこうした不正なブール値データの格納に関わるプロジェクトのクリーンアップを経験しているという。
SQLiteは複数の同時読み取りをサポートする一方、書き込みは同時に1つのみであり、デフォルトでは並行書き込み試行時に即座にSQLITE_BUSYエラーが発生する。提案されるbusyタイムアウト5000ミリ秒の設定により、この問題を軽減できるとみられる。また、Write-Ahead Log（WAL）はデフォルトで無効になっているが、PRAGMA journal_mode = WAL により有効化でき、パフォーマンスの向上が期待できるという。
エディション制度のメリット
エディション制度により、テクノロジーの進化に伴い妥当なデフォルト値は年ごとに変わるべきという考え方が実装される。例えば、将来のPRAGMA edition = 2034 では、WAL2の実装が含まれる可能性がある。このアプローチは、後方互換性を保ちながら、より優れたデフォルト設定へ段階的に移行するための実行可能な中間地点を提供するとみられる。
筆者の見立て
- SQLiteは業界標準のローカルデータストレージソリューションと考えている
- SQLiteは従来のRDBMSとファイルフォーマットの良いところを併せ持っていると論じている
- カスタム型別名の導入が、カスタム型名という特性を放棄するよりも優れたアプローチだと解釈している
- エディション制度は後方互換性と前進性のバランスを取る良い方法と考えている
この記事は元記事の事実のみに基づいて自動生成されました。
出典
出典：mort.coffee、「SQLite should have (Rust-style) editions」、https://mort.coffee/home/sqlite-editions/