为什么要使用数据库而不是仅将数据保存到磁盘？

我没有将数据库序列化为JSON，而是在必要时将其保存并加载到磁盘上。所有数据管理都是在程序本身上进行的，比使用SQL查询更快，更容易。因此，我从不了解为什么根本需要数据库。

为什么要使用数据库而不是仅将数据保存到磁盘？

1. 您可以查询数据库中的数据（询问问题）。
2. 您可以相对快速地从数据库中查找数据。
3. 您可以使用JOIN将两个不同表中的数据关联在一起。
4. 您可以从数据库中的数据创建有意义的报告。
5. 您的数据具有内置结构。
6. 给定类型的信息始终仅存储一次。
7. 数据库是ACID。
8. 数据库是容错的。
9. 数据库可以处理非常大的数据集。
10. 数据库是并发的；多个用户可以同时使用它们而不会破坏数据。
11. 数据库扩展性很好。

简而言之，您将受益于各种各样的非常聪明的人多年来开发的各种知名的，经过验证的技术。

如果您担心数据库过大，请查看SQLite。

尽管我同意罗伯特所说的一切，但他没有告诉您何时应该使用数据库，而不是仅仅将数据保存到磁盘。

因此，除了Robert关于可伸缩性，可靠性，容错性等方面所说的以外，还请考虑其他内容。

对于何时使用RDBMS，需要考虑以下几点：

• 您具有关系数据，即您有一个购买产品的客户，而这些产品有一个供应商和制造商
• 您拥有大量数据，并且需要能够快速找到相关信息
• 您需要开始担心先前发现的问题：可伸缩性，可靠性，ACID合规性
• 您需要使用报告或情报工具来解决业务问题

至于何时使用NoSQL

• 您有许多需要存储的非结构化数据
• 可扩展性和速度需求
• 通常，您不需要预先定义架构，因此，如果您有变更的要求，这可能是个好主意。

最后，什么时候使用文件

• 您拥有文件系统可以处理的合理数量的非结构化数据
• 你不在乎结构，关系
• 您无需担心可伸缩性或可靠性（尽管可以完成这些操作，具体取决于文件系统）
• 您不希望或无法处理数据库将增加的开销
• 您正在处理文件系统中的结构化二进制数据，例如：图像，PDF，文档等。

似乎没有人提到的一件事是记录索引。目前您的方法还不错，我认为您的数据集非常小，访问它的人很少。

随着变得越来越复杂，您实际上正在创建一个数据库。无论您要调用它什么，数据库只是存储在磁盘上的一组记录。无论您是要创建文件还是MySQL，SQLite或正在创建文件的文件，它们都是数据库。

您所缺少的是数据库系统中内置的复杂功能，这些功能使它们更易于使用。

我想到的主要内容是索引。好的，因此您可以在序列化数组或JSON字符串中存储10或20甚至100或1000条记录，并将其从文件中拉出并相对快速地进行迭代。

现在，假设您有10,000、100,000，甚至1,000,000条记录。当有人尝试登录时，您将不得不打开一个现在大小为数百兆字节的文件，将其加载到程序的内存中，取出大小相似的信息数组，然后迭代数十万条记录，以便找到您要访问的一条记录。

适当的数据库将使您能够在记录中的某些字段上建立索引，从而即使具有巨大的数据集，也可以查询数据库并非常快速地收到响应。将其与Memcached之类的东西，甚至是自制缓存系统相结合（例如，将搜索结果存储在单独的表中10分钟，并加载这些结果，以防其他人不久之后搜索相同的东西），以及您将获得快速的查询，而当您手动读取/写入文件时，使用如此大的数据集将无法获得这些查询。

与索引松散相关的另一件事是信息传递。如上所述，当您拥有数百或数千兆的文件时，必须将所有这些信息加载到内存中，然后手动对其进行迭代（可能在同一线程上），然后处理您的数据。

对于数据库系统，它将在自己的线程上运行，甚至在自己的服务器上运行。在程序和数据库服务器之间传输的所有内容都是一个SQL查询，而向后传输的所有内容都是您要访问的数据。您没有将整个数据集加载到内存中-发送和接收的所有内容仅占总数据集的一小部分。

当您拥有简单的数据（例如，在问题的注释中描述的事物列表）时，SQL数据库不会给您太多帮助。许多人仍在使用它们，因为他们知道随着时间的推移数据会变得更加复杂，并且有许多库使处理数据库变得不容易。

但是，即使您加载了一个简单的列表，将其保存在内存中，然后在需要时写入，仍然会遇到许多问题：

异常终止程序可能会丢失数据，或者在将数据写入磁盘时出了点问题，最终您可能会杀死整个文件。您可以滚动自己的机制来处理此问题，但是数据库会使用久经考验的技术为您处理此问题。

如果您的数据开始变得太大而又更新太频繁，则序列化所有数据并保存将是一项巨大的资源消耗，并使所有操作变慢。您必须开始研究如何对事物进行分区，因此它不会那么昂贵。数据库经过优化，可以以容错的方式仅将更改的内容保存到磁盘。它们也是经过设计的，因此您可以在任何给定时间快速加载所需的少量数据。

另外，您不必使用SQL数据库。您可以使用NoSQL的 “数据库”，很多都可以使用，只是使用JSON来存储数据。但这是通过容错方式完成的，并且可以在多台计算机之间智能地拆分，查询和智能拆分数据。

另外，有些人把事情混在一起。他们可能使用像Redis这样的NoSQL数据存储来存储登录信息。然后使用关系数据库在需要执行更多有趣查询的地方存储更复杂的数据。

我看到许多答案都集中在并发性和可靠性问题上。数据库除了并发性，可靠性和性能外，还提供其他好处。它们允许不理会如何在内存中表示字节和字符。换句话说，数据库允许程序员专注于“什么”而不是“如何”。

答案之一提到查询。“询问SQL数据库问题”随着问题的复杂性很好地扩展。随着代码在开发过程中的发展，诸如“获取全部”之类的简单查询可以轻松扩展为“在property1等于该值的情况下获取所有内容，然后按property2进行排序”，而不必担心程序员会为这种查询优化数据结构。通过为特定属性建立索引，可以提高大多数查询的性能。

其他好处是关系。使用查询，可以更交叉地交叉引用来自不同数据集的数据，然后再进行嵌套循环。例如，在一个系统中，用户和帖子是不同的数据集（或数据库表或JSON对象）的系统中，从少于3个帖子的用户中搜索所有论坛帖子，可以在不牺牲可读性的情况下进行一次查询。

总而言之，如果数据量很大（假设有1000个以上的对象），SQL数据库比普通数组更好，那么数据访问就非常简单，并且不同部分的代码可以访问不同的数据子集。

TLDR

听起来您已经为应用程序做出了本质上有效的短期数据存储技术决策-您选择编写自定义数据存储管理工具。

您坐在一个连续体上，可以选择向任一方向移动。

从长远来看，您很可能（几乎可以肯定，但不是100％）会遇到麻烦，并且最好改用现有的数据存储解决方案。您将不得不处理一些特定的，非常常见的，可预测的性能问题，并且最好使用现有工具，而不要自己动手使用。

听起来您已经编写了（小型）自定义数据库，该数据库已内置到应用程序中并直接由应用程序使用。我假设您依靠操作系统和文件系统来管理实际的磁盘写入和读取，并将该组合视为数据存储。

什么时候做什么

您正坐在最佳位置进行数据存储。操作系统和文件系统数据存储极为方便，可访问且可跨平台移植。这种组合已经存在了很长时间，您肯定可以在几乎所有标准部署配置上获得支持并运行您的应用程序。

这也是编写代码的简单组合-该API非常简单明了且基本，并且只需花费很少的代码即可使其正常工作。

通常，理想的情况是在以下情况下完成自己的工作：

• 制作新想法的原型
• 在性能上构建不太可能需要扩展的应用程序
• 受异常情况（例如缺乏用于安装数据库的资源）的约束

备择方案

您处于一个连续的选项中，您可以从此处获得两个“方向”，我认为是“向下”和“向上”：

下

这是最不可能应用的选项，但出于完整性考虑，在此处提供此选项：

如果需要，您可以关闭，也就是说，完全绕开OS和文件系统，并直接从磁盘真正读写。此选择通常仅在需要极高效率的情况下才有意义-例如，考虑最小/最小的MP3播放器设备，没有足够的RAM来运行完整的OS，或者诸如Wayback Machine之类的设备，它们需要非常高效的质量数据写入操作（大多数数据存储在较慢的写入与较快的读取之间进行权衡，因为这是几乎所有应用程序的绝大多数用法）。

上

这里有几个子类别-但是，它们并不是完全排他的。有些工具可以同时使用这两种工具，每种工具都提供某些功能，有些工具可以完全从一种模式转换为另一种模式，有些可以彼此叠加，从而为应用程序的不同部分提供不同的功能。

功能更强大的数据存储

您可能会发现自己需要存储越来越多的数据，同时仍然依靠自己的应用程序来管理数据操作的复杂性。您可以使用各种键值存储，并在不同程度上支持相关功能。NoSQL工具以及其他工具都属于此类别。

当以下内容描述您的应用程序时，这是扩大规模的明显途径：

• 读取内容异常繁重
• 您可以以较低的（短期）一致性保证权衡较高的性能（许多提供“最终一致性”）。
• 是“直接”管理大多数数据操作和缺乏一致性（实际上，起初您可能最终会使用第三方工具，尽管最终您会将其引入应用程序或自定义的书面中间层中） 。
• 您希望通过“相对简单”的数据操作需求来大规模扩展存储的数据量和/或搜索数据的能力。

这里有一些摆动的空间-您可以强制提高读取一致性，以降低读取速度。各种工具和选项提供数据操作api，索引和其他选项，它们或多或少适合于轻松编写您的特定应用程序。因此，如果以上几点几乎完全描述了您的应用程序，则您可能“足够接近”以使用功能更强大的数据存储解决方案。

著名示例：CouchDB，MongoDB，Redis，云存储解决方案（如Microsoft的Azure，Google App Data Store和Amazon的ECE）。

更复杂的数据处理引擎

与纯存储引擎相比，“ SQL”数据存储应用程序家族以及其他一系列应用程序被更好地描述为数据处理工具。它们提供了广泛的附加功能，不仅是数据存储，而且通常还超出了键值存储方面的可用功能。在以下情况下，您将采用此路径：

• 您绝对必须具有读取一致性，即使这意味着您会受到性能上的打击。
• 您正在寻找有效执行高度复杂的数据操作的方法-考虑非常复杂的JOIN和UPDATE操作，数据多维数据集和切片等...
• 您可以权衡以牺牲性能为代价（考虑强制性的，固定的数据存储格式，例如表格，这些表格不能轻易和/或有效地更改），您可以。
• 您有足够的资源来处理通常更复杂的工具和界面集。

这是数据库或数据存储的一种更“传统”的思维方式，并且已经存在了很长的时间-因此，这里有很多可用的方法，并且通常要处理很多复杂性。尽管这需要一些专业知识和知识，并且有可能构建简单的解决方案/避免很多复杂性，但您仍然有可能最终会使用第三方工具和库来为您管理其中的大部分内容。

众所周知的示例是MySQL，SQL Server，Oracle的数据库和DB2。

外包工作

有几种现代的第三方工具和库，它们相互之间插入数据存储工具和应用程序之间，以帮助您管理复杂性。

他们试图一开始拿走管理或操作数据存储的大部分或全部工作，并且理想情况下，仅当需要时，您才能顺利地过渡到复杂性。这是企业家精神和研究的活跃领域，最近的一些成果可立即获得和使用。

MVC工具（Django，Yii），Ruby on Rails和Datomic是著名的示例。这里很难做到公平，因为实际上有数十种工具和库充当各种数据存储区API的包装器。

PS：如果您喜欢视频而不是文本，则可能要观看Rich Hickey的一些数据库相关视频；他很好地阐明了选择，设计和使用数据存储的大部分想法。

文件系统符合NoSQL数据库的描述，因此我想说，在决定如何存储数据时，您绝对应该考虑使用该文件系统，而不仅仅是为了RDBMS而随意使用它，就像这里给出的一些答案一样。

文件系统（通常是NoSQL）的一个问题是处理数据之间的关系。如果这不是这里的主要阻碍因素，那么我想暂时跳过RDBMS。还请记住使用文件系统作为存储的积极方面：

• 零管理
• 低复杂度，易于设置
• 适用于任何操作系统，语言，平台，库等
• 目录只有配置设置
• 微不足道的测试
• 使用现有工具进行检查，备份，修改等都很简单
• 良好的性能特征，并通过操作系统进行了很好的调整
• 易于任何开发人员理解
• 没有依赖关系，没有额外的驱动程序
• 安全模型很容易理解，并且是操作系统的基础部分
• 数据无法从外部访问

（来源）

文件系统是一种数据库。也许不是像其他所有人都在谈论的RDBMS，但是从最严格的意义上讲，肯定是DB。您将提供用于查找数据（文件内容）的键（文件名），该文件具有抽象的存储空间和用于程序通信的API。

因此，您正在使用数据库。其他帖子可以争论不同类型的数据库的优点...

如果您有多个进程（用户/服务器）修改数据，则需要一个数据库。然后，数据库用于防止它们覆盖彼此的更改。

当您的数据大于内存时，您还需要一个数据库。如今，有了可用的内存，确实的确使得许多应用程序中的数据库使用已过时。

您的方法肯定比废话“内存数据库”更好。实质上，这是您的方法，但是增加了很多开销。

您应该经常问自己一个特定的应用程序是否需要RDBMS。在设计过程中构建了太多应用程序，这些过程在开始时会自动采用所有必需的工具和框架。关系数据库是如此普遍，许多开发人员像以前一样处理类似的应用程序，因此在项目开始之前会自动将它们包括在内。许多项目可以解决这个问题，所以不要过于苛刻。

您没有任何项目就开始了项目，并且它可以正常工作。您无需等待SQL就可以轻松启动并运行它。没有什么不妥。

随着该项目的扩展和要求变得越来越复杂，某些事情将变得难以构建。在研究和测试替代方法之前，您如何知道哪个更好？您可以问程序员，并在火焰中除草，“这取决于”来回答这个问题。学习后，您可以考虑愿意用几种语言编写的几行代码来处理数据库的某些好处。在某个时候，您正在重新发明轮子。

容易往往是相对的。有些框架可以构建网页并将表单连接到数据库表，而无需用户编写任何代码。我想如果您用鼠标挣扎，这可能是一个问题。谁都知道，这不是可伸缩的，也不是灵活的，因为上帝禁止您将所有内容紧密地耦合到GUI。非程序员只是构建了原型；在这里可以找到很多YAGNI。

如果您想学习由您选择的语言操纵的ORM而不是学习SQL，请继续学习，但是尝试安装，创建表并使用SQL将数据从流行的数据库中拉出（选择*从;不是令人着迷的东西）。这很容易做到。这就是为什么有人首先创建它们的原因。为了做出明智的决定，这似乎不是一笔巨大的投资。您可能也可以进行性能测试。

将数据保存到磁盘就是将其写入数据库，特别是如果您将每个对象放在其自己的文件中，并且文件名是记录的关键。为了最大程度地减少用于读取文件的查找时间，请根据密钥的前几个字符创建子目录。

例如key = ghostwriter将进入g / ho / stwriter.json或g / h / o / stwriter.json或g / ho / ghostwriter.json或g / h / o / ghostwriter.json。根据密钥的分配选择命名方案。如果它们是序列号，则5/4/3 / 12345.json优于其他方法。

那是一个数据库，如果它可以满足您的所有需求，那么就可以这样做。如今，它被称为NoSQL数据库，例如GDBM或Berkeley db。这么多的选择。首先弄清楚您需要什么，然后构建一个接口库来处理细节，也许是诸如get / set接口（如memcached或CRUD接口），然后，如果您需要更改数据库格式，则可以交换库。具有不同的特征。

请注意，某些SQL数据库（例如PostgreSQL和Apache Derby DB）将允许您在许多NoSQL格式（包括自己的本地数据库）上进行SQL查询。不确定MyBatis，但可能类似。

避免NoSQL炒作。阅读有关功能的信息，测试性能和功能，然后根据其与应用程序需求的匹配程度进行选择。

http://www.hdfgroup.org/HDF5/是人们并不经常考虑的另一种有趣且广泛使用的数据存储格式。

并发更新数据后，使用数据库的方法（很可能是内存数据库）可能会更正确，性能更高，同时代码也很容易，因为您根本没有担心并发更新，事务，缓存，异步I / O等。

您需要一个数据库来存储/检索QA，就像我们在此处发布的那样！一个简单的文件无法组织与不同主题相关的数据。