许多桌面用户不具备安装和管理多用户数据库服务器的技能，或者坦率地说，没有任何实际需求。然而，他们仍然需要使用和交换 SQL 数据库。不幸的是，许多开发人员没有将这种情况视为问题，并且至少最初以以下任何一种组合回应来驳回它：

这些论点在技术上没有错，但它们根本不适用于 soho 和企业用户的细分市场。这个领域的没有人抱怨安装服务器需要两次或一次鼠标点击而不是零次。但是，对于任何 SQL 服务器的完美、完全记录的安装向导，与这些用户目前获得的东西之间存在巨大差异。

每个人都说文件共享有多么棒。好吧，那么回答这个问题：Linux/KOffice 爱好者如何与运行 Windows/OO.o 的阿姨分享他的书籍或食谱数据库？一位员工如何将产品数据库从他的 MAC/OO.o 桌面发送给潜在的运行 Solaris/KOffice 的企业客户？如果接收者没有 root 密码或安装额外软件的权限，这在大多数办公室都是标准情况，该怎么办？总的来说，在现实世界中，“只需安装和配置这个”的态度没有意义，也无助于信息的自由流动。这种态度可能和必须安装新的字体或打印服务器才能打开文本文件一样不切实际，甚至是不可能的。

目前，自由软件用户缺少一个单文件 SQL 标准格式，它可以是 tar 或 ZIP 存档，其中包含通用前端让人们工作所需的一切：模式、数据、索引、表单结构等等。这样的数据库可以立即复制、上传到 Web 服务器或通过电子邮件发送，就像任何其他文件一样。用户可以确信接收者可以立即访问所有数据、查询和表单，即使它们看起来可能不同。最重要的是，如果这样的文件格式成为 OASIS 标准，那将是很好的，因为它会使其更容易被企业或政府场景接受。

在文本/电子表格/演示文稿领域，正确的事情已经在发生。两个最流行的免费办公软件套件 OO.o 和 KOffice 正在趋同于相同的默认文件格式，这是一个 OASIS 标准。这意味着今天能够在 OO.o KOffice 之间以及明天与任何其他 OASIS 兼容的应用程序之间透明地编写、读取和共享此类文档。这种程度的标准化也为自由软件提供了更多的可信度和力量。

为简单的 SQL 数据库做同样的事情难道不是很棒，并且现在不是时候了吗？当然，这不会阻止任何想要使用功能齐全的 RDBMS 守护程序的人使用它？今天，这样的数据库不受 OASIS 的涵盖或影响。我认为它们应该受到涵盖。本文的其余部分提出了一种实现此目标的方法。

应该趋同于此数据库标准的最初两个应用程序是 OpenOffice.org (OO.o) 和 KOffice。OO.o 具有数据源，这意味着它可以连接到外部 RDBMS 服务器，并且可以使用 dBase 格式的单文件数据库，但其功能非常有限。当我开始调查此事时，我了解到 OO.o 开发人员已经开始致力于改进对无服务器数据库引擎的支持。然而，标准化根本不是他们目前的目标。他们今天预计包含在 OO.o 2.0 中的（alpha 快照在此处 提供）是一种基于 XML 的数据库文件格式，其中包含除实际数据之外的所有内容（表单、报表、查询和管理信息）。

当我询问时，我被告知最有可能的文件格式选择是 HSQLDB，主要是因为它比其竞争对手支持更多的功能。就我个人而言，我反对这个选择，原因有四。第一个是性能（在此处阅读更多信息 链接 和 链接），特别是考虑到 OO.o 不需要像今天这样笨重。第二个原因是 HSQLDB 需要 Java，我不喜欢依赖第三方元素的想法，因为它更有可能导致这些单文件数据库在从 PC 移动到 PC 时在实践中无法工作。第三个原因是自由软件领域的许多其他应用程序和语言已经部分趋同于其他东西（稍后会详细介绍），所以我认为 OO.o 应该成为一个良好的社区公民并效仿。因此，我的第四个原因是：通过不在 OO.o 中提出便携式标准，OO.o 用户将处于对其他人说“是的，我们正在使用这个所谓的“自由”软件，但是如果你想透明地共享小型数据库，请强迫自己自由安装 OO.o、HSQLDB/Java 或上述任何组合”的境地。

KOffice 中的数据库界面称为 Kexi。Kexi 是一个用于创建数据库模式以及插入、查询和处理数据的集成环境。它可以不依赖 KDE 运行，可在 UNIX、MS Windows 和 Mac OS X 上运行。Kexi 已经创建了自包含的数据库文件 (.kexi)。查询和其他元数据存储在数据库本身内部，在名为 kexi__* 的特殊隐藏表中。此类元数据既具有视觉性质（列宽、详细的单元格格式），也具有功能性质（约束、错误消息）。这与今天在 OO.o 中发生的情况截然不同，在 OO.o 中，元数据存储在 XML 包中，而数据本身存储在其他地方。

显然，使用 Microsoft Access 格式 .mdb 不是一个选项。为什么要继续依赖另一种可能一夜之间发生变化的专有格式？据我所知，最好的解决方案是 SQLite，一个精简而高效的数据库引擎，已在 KDE 和 GNOME 中提供——分别嵌入在 Kexi 和 gnome-db 中——并且由不到 3 万行 C 代码构建而成。使用 SQLite，可以使用 独立的公共领域浏览器 在 Linux、Windows 和 Mac OS X 上设计和使用数据库。所有流行语言的包装器 已经存在；甚至 PHP 5.0.0 也已经嵌入了 SQLite，版本 2.8.14。

作为记录，目前可以使用 SQLite 数据库作为 OO.o 中的 外部数据源，使用 ODBC 驱动程序。详细说明可在 英文 和 法文 版本中找到。

选择此引擎的另一个原因可能是 SQLite 许可证，使其适合包含在专有产品中。今天 SQLite 的主要缺点是缺少某些功能，例如 ALTER TABLE、检查约束和引用完整性。然而，这些功能的添加，从 ALTER TABLE 开始，计划在未来几个月内完成。最后但并非最不重要的一点是，涉及的代码量很小，使得熟悉 SQLite 并添加新功能变得容易。SQLite 的作者 D. Richard Hipp 非常希望看到这个项目取得成功。

开发人员和最终用户都可以为实现这个便携式数据库梦想做出贡献。首先要做的是帮助将 SQLite 嵌入到 OO.o 中。关于实现此目标的可能方法，请在此处讨论 链接。您应该知道的其他内容是 开发者指南 的“Basic UNO”和“Database Access”部分，以及 SQLite 的相关 API。要加入的列表是 dev@dba.openoffice.org。开发人员热切期待您对这个特定子项目的支持。

当然，最困难的部分是制定所有这一切的完整标准。一旦 OO.o 嵌入了 SQLite，从使 OO.o、KOffice 和稍后所有其他用户之间直接交换数据库和表单成为可能还需要什么？最重要的是，KOffice 和 OO.o 团队是否有充分趋同以实现此标准的意愿？

在听取了我的论点后，OO.o 开发人员同意 SQLite 确实可能比 HSQLDB 更好，即使它需要额外的实施时间。Sun 对标准有着浓厚的兴趣，所以我希望它会支持我的这项提议。就 KOffice 而言，其所有核心开发人员的目标都是“所有 KOffice 应用程序要么遵循 OASIS 格式，要么帮助为当前未标准化的格式定义新的 OASIS 定义”。看起来不错，不是吗？当然，SQLite 只是数据库引擎部分。最伟大的工作是定义并以相同的方式使用所有其他相关信息——报表和表单如何表示和记录，查询如何存储等等。理论上，应该可以趋同于某种 XML 用户界面描述——也许是 UIML，另一个 OASIS 标准。

另一个需要处理的问题是当前文件格式方法的差异。在 Kexi 中，所有内容都添加到实际数据库的单独表中。在 OO.o 中，使用了带有管理 XML 流的 ZIP 存档。根据目前的计划，OO.o 2.0 应该将实际数据嵌入到该存档中。此外，OO.o 表单和报表是真实的 OO.o Writer 文档，由向导生成，其中包含一个宏，该宏在文档打开时用数据填充它。因此，Kexi 或 OO.o 都应该更改顶层文件格式本身（ZIP 存档或 SQLite DB），然后就查询和表单的通用格式达成一致。最初，在我看来，选择似乎已经做出，即使并非所有相关方都意识到了这一点。如果 OO.o 格式已成为开放的 OASIS 标准，并且 KOffice 正在采用它作为其自己的本机格式，并且 Kexi 是 KOffice 的一部分，那么还剩下什么？标准表单将是 OASIS 文本文档，就像它们在 OO.o 中已经存在的那样。但是，这是我的初步意见。重要的是，一种通用格式确实出现了，并且它被赋予了官方标准的地位。对我来说，SQLite 似乎是实现它的最佳方式。

首先，转到 此处 并为 OO.o 中的 SQLite 驱动程序投票。此外，投票支持在 Kexi 中添加对 OO.o 表单的支持。即使您自己不使用它们中的任何一个，您也可能会在某天收到或发送 SQLite 数据库，因此标准越广泛越好。最重要的是，从今天开始使用 SQLite。请记住，它也适用于 Windows 和 Mac。并且数据库，因为它们是自包含的，所以可以瞬间从一台机器移动到另一台机器。当然，报告您发现的任何错误，以帮助加速开发。

非常感谢 OO.o DBA 开发人员 Frank Schönheit，以及所有 KOffice 和 SQLite 开发人员，他们向我解释了完成这个难题所需的所有部分。