为什么要使用SQLite

揭开大多数业务应用程序的面纱，您将发现一些存储和使用结构化数据的方法。 无论是客户端应用程序，具有Web前端的应用程序还是边缘设备应用程序，都有可能需要某种嵌入式数据库。

SQLite是一个可嵌入的开源数据库，用C编写并可通过常规SQL查询，该数据库旨在涵盖这些用例以及更多用例。 无论您仅存储千字节的数据还是数千兆字节的Blob，SQLite的设计都旨在使其快速，可移植且可靠。

[发现Bossie奖的获得者：2018年最佳企业开源软件，用于软件开发，机器学习，云计算以及数据存储和分析。 ]

SQLite的最大优点之一是它几乎可以在任何地方运行。 SQLite已被移植到各种平台上：Windows，MacOS，Linux，iOS，Android等。 尤其是Windows用户，可以将预编译的二进制文件用于常规Win32，UWP，WinRT和.Net。 无论您的应用程序的部署目标是什么，都可能有可用的SQLite版本，或将C源代码移植到该目标的方法。

使用SQLite的应用程序不必用任何特定的语言编写，只要有某种方式可以绑定并与使用C语言编写的外部库一起使用即可。SQLite的二进制文件是独立的，因此它们不需要任何特殊的技巧即可部署-它们可以简单地放入与应用程序相同的目录中。

许多语言都将SQLite作为库具有高级绑定，并且可以将其与该语言的其他数据库访问层结合使用。 例如，Python将SQLite库作为标准问题元素与Python解释器的常规版本捆绑在一起。 此外，第三方已经编写了使用SQLite的各种ORM和数据层，因此您不必停留通过原始SQL字符串访问SQLite（这不仅笨拙而且潜在危险）。

最后，SQLite的源代码是公共领域，因此可以在没有实际限制的情况下在其他程序中重用。

SQLite最常见，最明显的用例是用作常规的，面向表的关系数据库。 SQLite支持事务和原子行为，因此程序崩溃甚至断电都不会使数据库损坏。

SQLite具有高端数据库中的功能，例如全文本索引和对JSON数据的支持。 通常以半结构化格式（例如YAML或XML）填充的应用程序数据可以存储为SQLite表，从而可以更轻松地访问和更快速地处理数据。

SQLite还提供了一种快速而强大的方法来存储程序的配置数据。 开发人员可以使用SQLite作为这些文件的接口，而不必像YAML那样分析文件格式，通常比手动操作它们要快得多。 SQLite可以像对待本地数据库表一样使用内存中的数据或外部文件（例如CSV文件），从而提供了一种方便的方式来查询该数据。

由于SQLite是单个独立的二进制文件，因此很容易与应用程序一起部署并根据需要随应用程序一起移动它。 SQLite创建的每个数据库还包含一个文件，可以通过SQL命令对其进行压缩或优化。

SQLite的第三方二进制扩展添加了更多功能。 SQLCipher向SQLite数据库文件添加256位AES加密。 另一个SQLite-Bloomfilter允许您从给定字段中的数据创建bloom过滤器 。

许多其他第三方项目为SQLite提供了其他工具，例如允许从Visual Studio Code中浏览数据库的Visual Studio Code扩展 ，或SQLite的LiteCLI交互式命令行。 GitHub上精选的SQLite资源列表包括更多内容。

SQLite通常与MySQL（或MariaDB）进行比较，后者是广泛使用的开源数据库产品，是当今应用程序堆栈的主要内容。 尽管SQLite可能类似于MySQL，但有很多地方可以将这两个数据库区分开来，并且有充分的理由根据使用情况将一个数据库优先于另一个数据库。

资料类型

SQLite的数据类型相对较少-BLOB，NULL，INTEGER和TEXT。 另一方面，MySQL（或MariaDB）具有专用于日期和时间的数据类型，各种精度的整数和浮点数等等。

如果您存储的数据类型相对较少，或者要使用数据层对数据执行验证，则SQLite很有用。 但是，如果希望数据层提供自己的验证和规范化，请使用MySQL（或MariaDB）。

配置和调整

SQLite的配置和调整选项很少。 SQLite的大多数内部或命令行标志都处理极端情况或向后兼容。 这符合SQLite的整体简化哲学：使默认选项非常适合大多数常见用例。

MySQL（或MariaDB）拥有一个由数据库和安装特定的配置选项组成的名副其实的林，包括排序规则，索引编制，性能调整等。这些丰富的选项是MySQL提供更多功能的结果。 您可能需要对MySQL进行更多调整，但这很可能是因为您首先尝试做更多事情。

单用户数据库与多用户数据库

SQLite最适合具有单个并发用户的应用程序，例如桌面或移动应用程序。 MySQL和MariaDB旨在处理多个并发用户。 MySQL和MariaDB也可以提供集群和横向扩展解决方案，而SQLite则不能。

SQLite远非唯一可嵌入的数据库。 许多其他功能提供相似的功能，但强调不同的用例或部署模型。

• Apache Derby ：一个可嵌入的SQL引擎，也由Oracle重新打包为Java DB。 由于Derby是用Java编写的，并且需要JVM，因此它主要是为嵌入Java应用程序而设计的。
• 嵌入式Firebird ：运行跨平台并具有许多高端功能的Firebird数据库可作为可嵌入客户端应用程序中的库使用。 它的功能集与SQLite相比很好，但是SQLite具有更大的用户社区和支持基础。
• 领域 ：为移动环境（主要是Android）设计的高性能关系数据库，但也可以支持Windows等桌面环境。 但是，Realm是基于对象的，并且不使用SQL查询-如果您不想使用SQL，则很好，但是如果SQL熟悉且舒适，则不好。
• VistaDB ：.Net运行时的嵌入式数据库。 VistaDB提供特定于.Net各种版本和版本的版本，并具有许多企业功能，例如全数据库加密。 但是，这是一种商业产品，而不是开放源代码。
• Berkeley DB ：一个Oracle项目，名义上是键/值存储，但是在最近的版本中使用SQLite作为处理SQL查询的一种方法。 Berkeley DB的基础数据库引擎具有SQLite无法比拟的性能增强，例如能够处理多个同时的写操作。

SQLite的设计选择使其非常适合某些情况，但不适用于其他情况。 以下是一些SQLite不能正常运行的地方：

• 使用SQLite功能的应用程序不支持。 SQLite不支持，并且在许多情况下将不尝试支持许多关系数据库功能 。 许多都是极端情况，但是即使其中之一也可能破坏交易。
• 需要横向扩展设计的应用。 SQLite实例是单个且独立的，它们之间没有本地同步。 它们不能联合在一起或组成集群。 使用横向扩展设计的任何软件应用程序都不能使用SQLite。
• 具有来自多个连接的同时写入操作的应用程序。 SQLite锁定数据库以进行写操作，因此任何涉及多个同时写操作的操作都可能导致性能问题。 但是，具有多个同时读取的应用程序通常运行速度很快。 SQLite 3.7.0和更高版本提供了预写日志记录模式，以使多个写入工作更快，但是它具有一些限制。 作为替代方案，可以考虑上述的Berkeley DB。
• 需要强数据输入的应用程序。 SQLite的数据类型相对较少-例如，没有本地日期时间类型。 这意味着强制执行这些类型将需要由应用程序处理。 如果您希望数据库（而不是应用程序）对日期时间值的输入进行规范化和约束，则SQLite可能不适用于您。

From: https://www.infoworld.com/article/3331923/why-you-should-use-sqlite.html