OpenDocumentがSQLiteを使用したらどうなるか？

2025年9月5日原文(sqlite.org)

概要

OpenDocument プレゼンテーション(ODP)形式の課題と設計思想の考察
ZIPアーカイブの代替として SQLite データベース利用の提案
ファイルサイズ・速度・メモリ使用量・ユーザー体験の改善案
将来のファイルフォーマット設計 への示唆
技術的検証と実験的改善案の紹介

Small. Fast. Reliable.Choose any three. SQLiteを活用したファイルフォーマット設計の思考実験

OpenDocument ファイル形式（特にODP）は、ZIPアーカイブ内にXMLや画像ファイルを格納する構造
本稿は現行仕様の批判ではなく、 将来のファイルフォーマット設計 の改善案を示す思考実験
ZIPの代わりに SQLiteデータベース をコンテナとして採用する利点を検討

OpenDocumentとODPファイルの現状

OpenDocumentは ワープロ・表計算・プレゼン資料 用の標準ファイル形式
ODPファイルはZIPアーカイブで、XML（content.xml, styles.xml, meta.xml, settings.xml）と画像ファイル群を格納
例：49ページのプレゼン資料では62枚の画像と複数のXMLファイルを含む
mimetypeファイルでファイル種別を明示

ODP形式の制約

ZIPは カスタムバイナリ形式より優れている が、SQLiteなら更なる利点
ZIPは ファイル単位の更新が困難 で、部分更新やクラッシュ耐性に難
全体書き換え が必要なため、保存・起動が遅い。SSDの書き換え寿命にも影響
全データをメモリ展開 する設計で、複数資料編集時に大量メモリ消費
クラッシュリカバリが煩雑で、ユーザー体験が悪化
XMLはテキストだが、 巨大な1行ファイル で可読性・編集性が低い

改善案1：ZIPをSQLiteに置換

ZIPの代わりに SQLiteデータベース を使うことで、ドキュメントの 部分更新 や 原子的保存 が可能

単純なテーブル設計例：

CREATE TABLE OpenDocTree(
  filename TEXT PRIMARY KEY,
  filesize BIGINT,
  content BLOB
);

実験結果：NeoOfficeで作成したODPをSQLite(SQLAR)に変換した場合、 ファイルサイズはほぼ同等かやや小さい
- ZIP生成ロジックによってはZIPのほうが小さい場合もあるが、差は僅少
SQLite利用時、変更ファイルのみ更新でき、 保存速度向上 ・ SSD負荷低減 が期待

改善案2：コンテンツの細分化

SQLiteは 多数の小さなデータ管理 にも適している
content.xmlのような 巨大なXMLファイル を、スライドごとなど小さな単位に分割して格納
- 例：スライドごとに1レコードとして保存
- テーブル設計例：
```
CREATE TABLE slide(
  pageNumber INTEGER,
  slideContent TEXT
);
CREATE INDEX slide_pgnum ON slide(pageNumber);
```
メリット：
- 起動時に必要なスライドのみ読み込み 可能
- メモリ使用量の大幅削減
- 編集・保存処理の効率化
- クラッシュ時の復旧容易化

今後のファイルフォーマット設計への示唆

SQLiteベースの設計 は、可搬性・信頼性・効率性を兼ね備える
部分更新 ・ 高速起動 ・ 低メモリ消費 ・ 堅牢なクラッシュリカバリ が実現可能
既存のZIPベース設計の課題を踏まえ、 次世代ファイルフォーマット への応用余地
ユーザー体験の向上 と 開発者の負担軽減 を両立するアーキテクチャ提案

Hackerたちの意見

面白い内容だけど、テキストドキュメントやスプレッドシートについても触れて、"バージョン管理"以外にどんな機能が追加されるのかを示してくれたらもっと意味があったと思う。私だけかもしれないけど、プレゼンテーション機能はOpenOfficeファミリーの中でもあまり使われてない部分だと思うんだよね。

└

読んでる間に、テキストを扱う方法の一つとして、リンクリスト形式でストレージするのはどうかなって考えてたんだ。そうするには、エディタがブロック概念で動く必要があると思うけど、ドキュメントエディタはそんな風には動かない気がする。スプレッドシートの方がシートや行・列レベルで分けられるから、ちょっと楽かもしれないね。今すぐ試してみたくなっちゃうな…

└

彼が最初の改善点として挙げた「ZIPをSQLiteに置き換える」は、他のODFフォーマットにも当てはまるだろうね。彼はXMLをSQLiteで小さなパーツに分けることを提唱してる。各スライドを新しいXMLレコードにするのは理にかなってるかも。スプレッドシートに移ると、今のODFがどうなってるかは分からないけど、各シートを別々のXMLにするのも良いかもしれない。Writeドキュメントについて考えると、良い小さな単位は何だろう？ページごとに1つのXMLは細かすぎると思うけど、章ごとに1レコードにするのはありかも。段落ごとに1レコードは意味がないと思うけど、いろんなアイデアを試すのは面白そうだね。

ヒップ博士は時々、sqliteデータベースのアプリケーションファイルフォーマットとしての利点を熱く語ることがあるよね。GitよりもFossilの方が優れているとも言ってるし。彼の主張は大体納得できるものだし、彼は本当に素晴らしいソフトウェア開発者の一人だから、私は彼の説教を我慢して聞いてる。彼は私の個人的なヒーローでもあるんだ。

└

これらはSQLiteの動作をよりよく理解するための思考実験だね。サポート文書はこうやって書かれるべきだと思う。他の人が読むためにね。彼は注意書きもかなり気を使ってたし。

sqliteベースのファイルフォーマットを作るのは比較的簡単そうだし、もし古いバージョンのLibreOfficeをアップグレードできないユーザーがいたら、プラグインを追加すればいいと思う。テキストやスプレッドシートファイルの利点についてもっと説明が必要だという他のコメントに同意するよ。でも、LibreOfficeの作業グループがもっと深く研究する価値があるアイデアだと思う。もしメモリ削減が本当に実現できて、それがクラッシュの減少につながるなら、他に利点がなくても大きなプラスになると思う。

私はサイドプロジェクトであるバーチャルホワイトボードのためにSQLiteを試してるんだけど、まだ完全には理解できてないけど、ファイルシステムAPIとやり取りするよりはずっと楽な感じがする。まだ解決できてない問題は、同期やコラボレーションがどう絡むかなんだ。今のところ考えてるのは：1. プレーンテキスト形式（JSONとか）またはgitでバージョン管理されたSQLiteダンプファイル 2. 何か現代的なローカルファーストのCRDT（Turso、libsql、Electric SQL） 3. ローカルでも動かせるサーバー/クライアントアーキテクチャ。これに成功した人いる？

└

SQLiteには、変更のグループを記録して再生するためのセッション拡張が組み込まれてるよ。必要な処理も全部含まれてる。セッションを解決策として推奨するわけではないけど、他のものと比較するのは良いアイデアだと思う。https://sqlite.org/sessionintro.html これにはCレベルのAPIがあるよ。Pythonが分かっていて、プロトタイピングや探索をしたいなら、私のSQLiteラッパーが役立つかもしれない。セッション拡張をサポートしてるからね。これが使い方の例だよ： https://rogerbinns.github.io/apsw/example-session.html

└

CRDTは、オフライン作業が多い場合にとても頑丈な選択肢だよ。

SQLiteをアプリケーションフォーマットとして使うなら、注意してほしいことがある。BLOBタイプはサイズが2GiBに制限されてる（int32）。使い方によってはそれが高いと感じるかもしれないし、そうでないかもしれない。SQLiteデータベースにそんなにバイナリデータを保存するのは適切じゃないって人もいるけど、アプリケーションフォーマットは通常、大きなバイナリデータを一つのファイルにまとめる必要があるから、複数のファイルを一緒にコピーして動かすよりはいいと思う。

└

データを複数のBLOBに分けることができるよ。

SQLiteをアプリケーションファイルフォーマットとして使うなら、以下のことをすべきだよ：1. secure_deleteプラグマを有効にすること。https://antonz.org/sqlite-secure-delete/> これでユーザーが何かを削除したとき、データが実際に消えるようになる。そうしないと、ユーザーがアプリのファイルを他の人と共有したとき、受取人が送信者が削除したと思っていた情報を復元できちゃうかもしれない。2. https://www.sqlite.org/security.html#untrusted_sqlite_databa...> にある「信頼できないSQLiteデータベースファイル」のオプションを有効にして、信頼できないソースからのファイルを開くときに安全性を高めること。メールの添付ファイルを開いたときにハッキングされたくないよね。3. セキュリティの脆弱性を扱う際、SQLiteの開発者はこのユースケースをニッチだと考えていることに注意してほしい（「実際のアプリケーションで信頼できないソースからSQLiteデータベースファイルを開くことは少ない」と言ってるし）。彼らはSQLiteに対してファズテストを行う人々にイライラしているみたいだけど、アプリケーションファイルフォーマットは絶対にファズテストすべきだと思う。https://www.sqlite.org/cves.html 彼らはSQLiteをアプリケーションファイルフォーマットとして使う方法についてのマーケティングページでこれらのことを全く言及していない。

Hacker Newsで議論の続きを見る

ハクソク