编程与软件工程sqlite.org
如果 OpenDocument 使用 SQLite 会怎样？
What If OpenDocument Used SQLite?
2017 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 SQLite 官网的一篇“假设”文章，探讨如果 OpenDocument（ODF）改用 SQLite 而不是 ZIP+XML 来存放文档，会怎样。它借这个思想实验讨论数据库作为文档容器的可行性，以及效率、增量更新与可移植性之间的取舍。
为什么经久不衰：它把文件格式设计中的效率、增量更新与长期归档、开放标准之间的张力摆上台面，十多年后仍值得读。
HN 评论精选
从百年归档角度反对：ZIP+XML 可读可复现，SQLite 二进制格式版本依赖强、较难自描述。
我想从数据归档的角度审视这个“假设”。ZIP 使用有完整文档、易复现且被广泛实现的 deflate 算法，可以合理假设 100 年后有人还能解压 OpenDocument 文件；内容是 XML，基本就是文本，任何简单文本编辑器都能读和解析，而且 XML 对文档内容多少有自描述性。SQLite 数据库是二进制格式，且已知会周期性变化；100 年后要读取 SQLite 文件，必须知道确切文件版本，并能回溯历史找到那个版本（或兼容版本），还要能为当时的 CPU 架构编译它。即使把对应版本的二进制格式文档一起放进数据库可缓解，但据我所知完整文档（代码之外）并不存在；最终产物是关系数据库，也比 XML 更不自描述。我认为保留低效的 ZIP+XML 好得多。
falcolas查看英文原文
I'd like to take a moment and look at this "what if" from the point of view of data archiving. Zip files use a well documented, easily-reproducable and widely implemented deflate algorithm. It's reasonable to assume that someone could, 100 years from now, unzip an OpenDocument file. The contents are XML files - basically text - which can be read with any simple text editor and parsed. The XML is also at least somewhat self-documenting regarding the contained document. SQLite databases have a binary format which is known to change periodically. An attempt to read a SQLite file in 100 years would have to know the exact version of the file, and be able to reach back through history to find that version of SQLite (or a compatible version), and find a way to compile it for whatever CPU architecture exists in 100 years. This could be mitigated by including the appropriately versioned documentation of the binary format with the database itself - however to the best of my knowledge, full documentation of the binary format (outside the code) does not exist. The end product - a relational database - would also be less self-documenting than the XML version. IMO, it would be much better to keep the inefficient zipped XML files. [EDIT]: The binary file format: https://www.sqlite.org/fileformat.html Learn something new every day.
SQLite 对网络文件系统支持不佳，与 fopen 的类比不成立。
对我来说，不做这种事最大的原因是 SQLite 至今经常拒绝在网络文件系统上工作。我理解这是作者们在锁不可靠时对潜在损坏很谨慎，但如果他们真想说“SQLite 与 fopen() 竞争”，就得想办法绕过这一点，因为 fopen() 不会这样。
mjw1007查看英文原文
For me, the biggest reason not to do this sort of thing is that SQLite still often refuses to work over network filesystems. I appreciate that this is because the authors are being careful about possible corruption when locking isn't working properly, but if they really mean the « SQLite competes with fopen() » line they need to find a way to get round this, because fopen() doesn't do that.
用 SQLite 等于回到二进制 Office 老路；ODF 选 zip/XML 是为可移植和实现独立。
这会绕回二进制 .doc/.xls 的糟糕旧时代，那些格式用高效数据存储来支持快速增量更新。OpenDocument 和它的竞争者 OOXML 都出于可移植性使用 zip/XML。是的，它们效率更低，但也完全独立于任何特定软件实现（注：OOXML 有些部分依赖 MS Office 实现，ODF 则完全由规范描述）。
peterkelly查看英文原文
That would be coming full circle, and going back to the bad old days of binary .doc and .xls files, which used an efficient data store for fast incremental updates: https://www.joelonsoftware.com/2008/02/19/why-are-the-microsoft-office-file-formats-so-complicated-and-some-workarounds/ OpenDocument and its competitor (OOXML) both use zip/XML for portability reasons. Yes, they're less efficient. But they're also completely independent of any specific software implementation [1]. [1] Mostly - OOXML has some parts that depend on MS Office's implementation. But ODF is completely described by the spec.
只有 SQLite 能读 SQLite；它支持广但归档质量和简单性不如 ZIP/XML。
我是 SQLite 的忠实粉丝，但这种营销让我有点反感。ZIP 和 XML 是流行标准，有几十个实现；据我所知，唯一能读 SQLite 数据库的只有 SQLite。当然，SQLite 支持很好、跑在很多平台、还会存在很久；但它归档质量更低，而且内在更复杂（即使这种复杂性被封装得很好）。
btrask查看英文原文
I'm a big fan of SQLite, but this kind of marketing puts me off a bit. ZIP and XML are popular standards with dozens of implementations. The only thing that can read an SQLite DB is SQLite, AFAIK. To be sure, SQLite is very well supported, runs on tons of platforms and is going to be around for a long time. But still, it is less archival quality, and more inherently complex (even though that complexity is very well encapsulated).
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选