本节重点介绍了 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 库的大小小于 500KiB（在 ix86 上使用 GNU 编译器套件中的“大小”实用程序进行测量。）可以在编译时禁用不需要的功能以进一步减少 如果需要，库的大小要低于 300KiB。 大多数其他 SQL 数据库引擎都比这大得多。 IBM 吹嘘其最近发布的 CloudScape 数据库引擎“仅”是一个 2MiB 的 jar 文件 - 即使在压缩后也比 SQLite 大一个数量级！ Firebird 声称其客户端库只有 350KiB。 它和 SQLite 一样大，甚至不包含数据库引擎。 Oracle 的 Berkeley DB 库是 450KiB，它省略了 SQL 支持，只为程序员提供简单的键/值对。
动态类型
大多数 SQL 数据库引擎使用静态类型。数据类型与表中的每一列相关联，并且只允许在该列中存储该特定数据类型的值。 SQLite 通过使用动态类型放宽了这一限制。在动态类型中，数据类型是值本身的属性，而不是存储值的列的属性。 SQLite 因此允许用户将任何数据类型的任何值存储到任何列中，而不管该列的声明类型如何。 （此规则有一些例外：INTEGER PRIMARY KEY 列可能只存储整数。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 定义了允许用户添加新 SQL 函数和整理序列的 API。
翻译自 https://www.sqlite.org/different.html
本文由 至简 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为:
2021/08/11 15:42
翻译的不错！