本页重点介绍了 SQLite 的一些非同寻常的特性,这些特性使 SQLite 不同于许多其他 SQL 数据库引擎。
零配置
SQLite 在使用之前无需“安装”。没有“设置”过程。没有需要启动、停止或配置的服务器进程。无需管理员创建新的数据库实例或为用户分配访问权限。SQLite 不使用任何配置文件。无需执行任何操作来告诉系统 SQLite 正在运行。系统崩溃或断电后无需采取任何措施恢复。没有需要排查的问题。SQLite 只管工作。
其他更熟悉的数据库引擎在启动后运行良好。但最初的安装和配置过程可能会让人望而生畏。
无服务器
(另请参见 无服务器 文档页面。)
大多数 SQL 数据库引擎都作为单独的服务器进程实现。要访问数据库的程序使用某种进程间通信(通常是 TCP/IP)与服务器通信,以向服务器发送请求并接收结果。SQLite 的工作方式并非如此。使用 SQLite 时,要访问数据库的进程直接读取和写入磁盘上的数据库文件。没有中间服务器进程。
无服务器有优点也有缺点。主要优点是无需安装、设置、配置、初始化、管理和排查单独的服务器进程。这是 SQLite 是“零配置”数据库引擎的原因之一。使用 SQLite 的程序在运行之前无需管理支持来设置数据库引擎。任何能够访问磁盘的程序都可以使用 SQLite 数据库。
另一方面,使用服务器的数据库引擎可以提供更好的保护,防止客户端应用程序中的错误 - 客户端中的错误指针不会损坏服务器上的内存。而且,由于服务器是一个持久进程,因此可以更精确地控制数据库访问,从而实现更细粒度的锁定和更好的并发性。
大多数 SQL 数据库引擎都是基于客户端/服务器的。在那些无服务器的引擎中,SQLite 是唯一一个我知道的允许多个应用程序同时访问同一个数据库的引擎。
单个数据库文件
SQLite 数据库是一个普通的磁盘文件,可以位于目录层次结构中的任何位置。如果 SQLite 可以读取磁盘文件,那么它就可以读取数据库中的任何内容。如果磁盘文件及其目录是可写的,那么 SQLite 就可以更改数据库中的任何内容。数据库文件可以轻松地复制到 USB 记忆棒上或通过电子邮件共享。其他 SQL 数据库引擎倾向于将数据存储为大量文件。通常这些文件位于一个标准位置,只有数据库引擎本身才能访问。这使得数据更安全,但也更难访问。一些 SQL 数据库引擎提供了直接写入磁盘并绕过文件系统的选项。这提供了额外的性能,但代价是设置和维护复杂性大大增加。
稳定的跨平台数据库文件
SQLite 文件格式是跨平台的。在某台机器上写入的数据库文件可以复制到另一台具有不同架构的机器上并使用。大端序或小端序、32 位或 64 位都没有关系。所有机器都使用相同的格式。此外,开发人员承诺保持文件格式稳定并向后兼容,因此 SQLite 的新版本可以读取和写入旧的数据库文件。大多数其他 SQL 数据库引擎要求您在将数据库从一个平台迁移到另一个平台时以及在升级到软件的新版本时经常进行转储和恢复操作。
紧凑
在优化大小后,启用了所有功能的整个 SQLite 库 大小不到 1MiB(使用 GNU 编译器套件中的“size”实用程序在 ix86 上测量)。可以在编译时禁用不必要的特性,以进一步减小库的大小。大多数其他 SQL 数据库引擎都比这大得多。IBM 吹嘘其最近发布的 CloudScape 数据库引擎“仅”是一个 2MiB 的 jar 文件 - 即使在压缩后也比 SQLite 大一个数量级!Firebird 吹嘘其客户端库仅为 350KiB。这与 SQLite 一样大,甚至不包含数据库引擎。Oracle 的 Berkeley DB 库为 450KiB,它省略了 SQL 支持,只为程序员提供简单的键值对。
显式类型
大多数 SQL 数据库引擎使用静态类型。将数据类型与表中的每个列相关联,并且只允许将该特定数据类型的的值存储在该列中。SQLite 通过使用显式类型来放宽此限制。在显式类型中,数据类型是值本身的属性,而不是存储值的列的属性。因此,SQLite 允许用户将任何数据类型的任何值存储到任何列中,而不管该列的声明类型如何。(此规则有一些例外:INTEGER PRIMARY KEY 列只能存储整数。当 SQLite 能够将值强制转换为列的声明数据类型时,SQLite 会尝试这样做。)据我们所知,SQL 语言规范允许使用显式类型。然而,大多数其他 SQL 数据库引擎都是静态类型的,因此有些人认为 SQLite 中使用显式类型是一个错误。但 SQLite 的作者坚信这是一项功能。SQLite 中使用显式类型是一个经过深思熟虑的设计决策,在实践中被证明使 SQLite 更可靠、更易于使用,尤其是在与 Tcl 和 Python 等动态类型编程语言结合使用时。
可变长度记录
大多数其他 SQL 数据库引擎为大多数表中的每行分配固定的磁盘空间。它们使用特殊技巧来处理长度可能差别很大的 BLOB 和 CLOB。但对于大多数表来说,如果您将列声明为 VARCHAR(100),那么无论您实际存储在该列中的信息有多少,数据库引擎都会分配 100 字节的磁盘空间。相比之下,SQLite 只使用实际存储一行信息所需的磁盘空间。如果您在一个 VARCHAR(100) 列中存储一个字符,那么只占用一个字节的磁盘空间。(实际上是两个字节 - 在每列的开头有一些开销来记录其数据类型和长度。)
SQLite 使用可变长度记录有很多优点。很明显,它会生成更小的数据库文件。它还会使数据库运行得更快,因为要移动进出磁盘的信息更少。而且,使用可变长度记录使 SQLite 能够使用显式类型而不是静态类型。
可读的源代码
SQLite 的源代码旨在可读,并供普通程序员访问。所有过程、数据结构以及许多自动变量都经过仔细注释,包含有关它们的功能的有用信息。省略了样板注释。
SQL 语句编译成虚拟机代码
每个 SQL 数据库引擎都会将每个 SQL 语句编译成某种内部数据结构,然后使用该结构来执行语句的工作。但在大多数 SQL 引擎中,该内部数据结构是相互关联的结构和对象的复杂网络。在 SQLite 中,语句的编译形式是机器语言表示形式的简短程序。数据库用户可以通过在查询前面添加 EXPLAIN 关键字来查看此 虚拟机语言。SQLite 中使用虚拟机对库的开发非常有利。虚拟机在 SQLite 的前端(解析 SQL 语句并生成虚拟机代码的部分)和后端(执行虚拟机代码并计算结果的部分)之间提供了一个清晰、定义明确的连接。虚拟机允许开发人员清楚地看到 SQLite 尝试对编译的每个语句进行的操作,并且以易于阅读的形式查看这些操作,这对调试非常有帮助。根据编译方式的不同,SQLite 还具有跟踪虚拟机执行的能力 - 在执行时打印每个虚拟机指令及其结果。
公有领域
SQLite 的源代码属于公有领域。对核心源代码的任何部分均不主张版权。 (文档和测试代码则不同 - 文档和测试逻辑的某些部分受开源许可证管理。) 所有对 SQLite 核心软件做出贡献的人员都签署了宣誓书,明确放弃对代码的任何版权权益。这意味着任何人都可以合法地对 SQLite 源代码执行任何他们想做的事情。还有其他 SQL 数据库引擎具有宽松的许可证,允许广泛自由地使用该代码。但这些其他引擎仍然受版权法的约束。SQLite 的不同之处在于版权法根本不适用。
其他 SQL 数据库引擎的源代码文件通常以一条注释开头,描述您查看和复制该文件的法律权利。SQLite 源代码不包含任何许可证,因为它不受版权法约束。SQLite 源代码没有使用许可证,而是提供了一种祝福
愿你行善不作恶
愿你找到自我宽恕,也宽恕他人
愿你自由分享,永远不要索取超过给予。
SQL 语言扩展
SQLite 为 SQL 语言提供了一些在其他数据库引擎中通常找不到的增强功能。前面已经提到了 EXPLAIN 关键字和显式类型。SQLite 还提供了一些语句,例如 REPLACE 和 ON CONFLICT 子句,它们允许对约束冲突的解决方式进行额外的控制。SQLite 支持 ATTACH 和 DETACH 命令,允许将多个独立数据库一起使用在同一个查询中。SQLite 还定义了 API,允许用户添加新的 SQL 函数 和 排序规则。
本页最后修改于 2024-05-08 11:54:12 UTC