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

#1 楼

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

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

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

#2 楼

尽管我同意罗伯特所说的一切，但他并没有告诉您何时应该使用数据库，而不仅仅是将数据保存到磁盘上。
因此，除了罗伯特所说的有关可伸缩性，可靠性和容错性的内容外，还请注意这一点。等。
关于何时使用RDBMS，需要考虑以下几点：

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

关于何时使用NoSQL的问题

您需要存储很多非结构化的数据
可伸缩性和速度需求
您通常不需要预先定义架构，因此，如果您有变化的需求，则可能会最好是

最后，什么时候使用文件

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

#3 楼

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

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

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

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

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

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

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

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

#4 楼

TLDR
听起来您已经为应用程序做出了本质上有效的短期数据存储技术决策-您选择编写一个自定义数据存储管理工具。
您正处于一个连续的过程中，具有多种选择
从长远来看，您很可能（几乎，但不一定100％）会遇到麻烦，最好改用现有的数据存储解决方案。您将不得不处理一些特定的，非常常见的，可预测的性能问题，并且最好使用现有工具，而不要自己动手使用。

听起来您已经写了一个（小型）自定义数据库，已内置到应用程序中并由应用程序直接使用。我假设您依靠操作系统和文件系统来管理实际的磁盘写入和读取，并将该组合视为数据存储。
何时做您做的事情
您坐在数据存储的最佳选择。操作系统和文件系统数据存储极为方便，可访问且可跨平台移植。这种组合已经存在了很长时间，您肯定可以在几乎所有标准部署配置上获得支持并运行您的应用程序。
这也是编写代码的简单组合-API非常简单-forward和basic，并且只需花费很少的代码即可使其起作用。
通常，在以下情况下，您最好做自己做的事：

制作新想法的原型
构建性能极不可能需要扩展的应用程序
受异常情况的约束，例如缺乏安装数据库的资源
替代方案
您处于连续状态选项，这里有两个“方向”，我认为是“下”和“上”：
下
这是最不可能应用的选项，但是它在这里为了完整起见：
您可以根据需要关闭系统，即完全绕开OS和文件系统，然后直接从磁盘真正读写。此选择通常仅在需要极高效率的情况下才有意义-例如，考虑最小/微小的MP3播放器设备，而没有足够的RAM来运行完整功能的OS，或诸如Wayback Machine之类的设备，它们需要非常高效的质量数据写入操作（大多数数据存储在较慢的写入与较快的读取之间进行权衡，因为这几乎是所有应用程序中绝大多数的常见用例）。
上层
这里有几个子类别-这些不是完全是独家的。有些工具可以同时使用这两种工具，每种工具都提供某些功能，有些工具可以完全从一种模式转换为另一种模式，有些可以彼此叠加，为应用程序的不同部分提供不同的功能。 >功能更强大的数据存储
您可能会发现自己需要存储越来越多的数据，同时仍要依靠自己的应用程序来管理数据操作的复杂性。您可以使用各种键值存储，并在不同程度上支持相关功能。 NoSQL工具以及其他工具都属于此类别。
当以下内容描述您的应用程序时，这是显而易见的扩展途径：

读取reliant异常繁琐
您可以权衡以更高的性能换取较低的（短期）一致性保证（许多提供“最终一致性”）。
可以“直接”管理大多数数据操作和缺乏一致性（实际上，您可以最初可能会最终使用第三方工具，尽管最终您会将其带入您的应用程序或自定义的书面中间层中。）
您正在寻求大规模扩展要存储的数据量和/或您具有“相对简单”的数据操作要求的搜索能力。

这里有一些摆动的空间-您可以强制提高读取一致性，以降低读取速度。各种工具和选项提供数据操作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与数据库有关的一些视频；他很好地阐明了选择，设计和使用数据存储所涉及的大多数想法。

#5 楼

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

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

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

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

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

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

#6 楼

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

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


零管理
低复杂度，易于设置
与任何操作系统，语言，平台，库等
仅配置设置为目录
要测试的临时对象
要使用现有工具进行检查，备份，修改等的临时成员
良好的性能特征并由操作系统进行了很好的调整
任何开发人员都易于理解
没有依赖关系，没有额外的驱动程序
安全模型很容易理解，并且是操作系统的基本组成部分
数据不可从外部访问
>

#7 楼

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

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

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

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

#8 楼

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

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

#9 楼

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

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

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

#10 楼

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

您在没有一个项目的情况下开始了您的项目，并且它可以正常工作。您无需等待SQL就可以轻松启动并运行它。这没什么不对。

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

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

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

#11 楼

将数据保存到磁盘就是将其写入数据库，尤其是如果您将每个对象放在其自己的文件中，并且文件名是记录的键。为了最大程度地减少读取文件的查找时间，请根据密钥的前几个字符创建子目录。例如，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。有很多选择。首先弄清楚您需要什么，然后构建一个接口库来处理细节，也许是诸如memcached之类的get / set接口或CRUD接口，然后如果您需要更改一个库的格式，便可以交换库了。具有不同的特征。

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

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

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

#12 楼

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

#13 楼

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