如果您需要做的只是将一些应用程序数据存储在某个地方，那么通用RDBMS甚至SQLite可能会过大。在某些情况下，序列化对象并将它们写入文件可能会更简单。SQLite的一个优点是，如果您有很多此类信息，则所有信息都包含在一个文件中。缺点是阅读起来比较困难。例如，如果将数据序列化为YAML，则可以使用任何文本编辑器或Shell读取文件。

就我个人而言，我将使用一些“已编译的数据库查询”字节码，该字节码将在客户端应用程序内部组装一次并传递给数据库。

这就是某些数据库API的工作方式。签出静态SQL和准备好的语句。

我有什么理由不自己写它，而是改用SQL数据库吗？

如果您需要许多功能，则在某个时候使用现有RDMBS会比从头开始编写自己的数据库更容易。如果您不需要很多功能，则更简单的解决方案可能更明智。

数据库产品的重点是避免为每个新程序编写数据库层。是的，现代的RDMBS可能并不总是适合每个项目。这是因为它们的设计是非常通用的，因此在实践中，您将始终获得不需要的其他功能。这并不意味着拥有自定义解决方案会更好。手套并不一定总是很合适。

更新：

但是，为什么要使用SQL语言与这样的数据库进行交互呢？

好问题。

答案可以在EF
Codd于1970年由IBM出版的描述关系模型“大型共享数据库的数据关系模型”的原始论文中找到。本文描述了当时的现有数据库技术所存在的问题，并解释了为什么关系模型优越。

使用关系模型以及使用SQL之类的逻辑查询语言的原因是数据独立性。

数据独立性在本文中定义为：

“ …应用程序和终端活动不受数据类型增长和数据表示形式更改的影响。”

在关系模型之前，数据库的主导技术被称为网络模型。在此模型中，程序员必须知道数据的磁盘结构并手动遍历树或图。关系模型允许人们针对独立于磁盘上数据的物理表示的概念或逻辑方案编写查询。逻辑方案与物理方案的这种分离是我们使用关系模型的原因。有关此问题的一个多，这里是从数据库类的一些幻灯片。在关系模型中，我们使用基于逻辑的查询语言（例如SQL）来检索数据。
Codd的论文更详细地介绍了关系模型的好处。读一读。

与研究论文中通常使用的查询语言相比，SQL是一种易于输入到计算机中的查询语言。研究论文通常使用关系代数或关系演算来编写查询。

总而言之，我们使用SQL是因为我们碰巧对数据库使用关系模型。

如果您了解关系模型，那么不难理解为什么SQL就是这种方式。因此，基本上，您需要更深入地研究关系模型和数据库内部结构，才能真正理解我们为什么使用SQL。否则可能有点神秘。

更新2：

SQL是人与数据库之间的接口。问题是为什么我们必须将其用于应用程序/数据库交互？我仍然要求提供人类编写/调试SQL的示例。

因为数据库是关系数据库，所以它仅理解关系查询语言。在内部，它使用类似关系代数的语言来指定查询，然后将其转变为查询计划。因此，我们以一种我们可以理解的形式（SQL）编写查询，DB接受我们的SQL查询并将其转换为内部查询语言。然后，它接受查询并尝试找到用于执行查询的“查询计划”。然后，它执行查询计划并返回结果。

在某些时候，我们必须以数据库可以理解的格式对查询进行编码。数据库仅知道如何将SQL转换为其内部表示，这就是为什么链中始终存在SQL的原因。这是无法避免的。

使用ORM时，只需在SQL之上添加一个层。SQL仍然存在，只是隐藏着。如果您具有用于将请求转换为SQL的更高层，则无需直接编写SQL，这在某些情况下是有益的。有时我们没有这样的层能够执行所需的查询，因此我们必须使用SQL。