Что если OpenDocument хранил бы данные в SQLite, а не в ZIP?

Иллюстрация показывает выбор между традиционным ZIP-контейнером и возможностью использования SQLite для формата OpenDocument, подчёркивая идею более быстрого и надёжного хранения данных.

Форматы офисных документов кажутся чем-то привычным и «застывшим»: Word хранит файлы в DOCX, LibreOffice — в ODT/ODP, и всё это упаковано в ZIP-архивы с XML внутри. Но инженеры SQLite предложили любопытный мысленный эксперимент: а что, если контейнером стал бы не ZIP, а сама база данных SQLite?

🔹 Проблемы ZIP-контейнера

📂 Полная перезапись при сохранении — поменяли одну букву в презентации на 50 МБ? LibreOffice перепакует весь архив, что медленно и убивает SSD.

🐢 Медленный старт — при открытии документа читается весь content.xml и все изображения, хотя пользователю нужна всего первая страница.

💾 Перегрузка памяти — 50 МБ ODP легко превращаются в 200 МБ RAM, особенно если у вас открыто несколько презентаций.

💥 Сложность восстановления после сбоев — приходится городить отдельные механизмы автосейва и диалог восстановления.

ZIP хорош для хранения «кучи файлов», но это ключ/значение-подход, а не полноценная модель данных.

🔹 Что даёт SQLite

📌 Инкрементные обновления — SQLite гарантирует атомарность: сохраняется только изменённый слайд, а не весь документ.

⚡ Быстрый старт — достаточно выполнить SELECT slideContent FROM slide WHERE pageNumber=1;, чтобы показать первый слайд без прогресс-баров.

🧠 Меньше памяти — можно держать в RAM только текущий и следующий слайд, остальное читать по запросу.

🗂️ Версионирование встроено — схема с таблицами slide и version позволяет хранить историю изменений прямо в файле, без внешних бэкапов.

🔍 Доступность контента — SQL-запросы открывают путь для сторонних скриптов: можно искать по тексту, вытаскивать заметки или делать аналитику прямо в документе.

🔹 Технический эскиз

CREATE TABLE slide(
slideId INTEGER PRIMARY KEY,
derivedFrom INTEGER,
content TEXT
);

CREATE TABLE version(
versionId INTEGER PRIMARY KEY,
priorVersion INTEGER,
checkinTime DATETIME,
comment TEXT,
manifest TEXT
);

Такой дизайн превращает файл в «мини-Git» для презентаций: можно мгновенно откатиться, хранить несколько веток или автоматически собирать разные версии.

🔹 Моё видение

Мне кажется, идея SQLite как формата хранения — это шаг от «файла» к «локальной базе знаний». Представьте:

• 🎞️ презентация открывается моментально, без полос загрузки;
• 🕒 каждая правка сохраняется как версия, как в Google Docs, но офлайн;
• 🛠️ разработчики могут писать плагины, которые обращаются к содержимому напрямую через SQL.

Да, ZIP проще и кросс-платформеннее, но будущее офисных форматов скорее за «умными контейнерами». SQLite уже доказал свою надёжность как встроенная база — почему бы не сделать её сердцем офисного документа?

Источники

• What If OpenDocument Used SQLite? — SQLite.org
• LibreOffice и спецификация ODF: OASIS OpenDocument