如何确定存储格式之间的区别，以及其中的一些示例用例？

我们有不同的方式来存储程序数据（在游戏，员工数据库，程序配置等中保存文件）：

• 纯文本（.ini和.conf）
• XML格式
• 数据库（MySQL，SQLite ...）
• .zip 包含多个文件（格式不同）的类似文件
• 二进制文件（.doc例如，由序列化工具创建的文件等）

上面列出的格式有哪些不同的用例，它们的优点与缺点（考虑速度，灵活性，文件大小，易用性...）之间有什么分别？如何在不同任务之间做出决定？

关于压缩格式：仅用于包含其他文件。它也可以是另一种压缩格式。这允许几个文件的结构，包括图像文件，声音文件和文本文件。例如，假设您有一种消息的存储格式，其中可能包含文件。压缩文件中可以包含以下文件：

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg

我使用如下：

纯文本

对于配置-通常使用YAML或.ini。我不赞成将其用于大多数用途，除非文本文件是所需的结果（例如，打印到文本，保存到文本等）

XML格式

用于配置和传输数据；例如导出，通过XSLT格式化等。作为便携式文件格式（例如SVG）很好。出色的操作工具和过滤器。

资料库

来自app / webapp内部的主数据存储。始终将其用作选择的存储。它可靠，健壮，并且内置了很多功能（事务，参照完整性，级联删除/更新，索引，速度）。最好与图层或ORM（IMO）一起使用。

单个文件存档（例如.zip）

适用于紧凑地存储相关的多个二进制流，例如仿真器的ROM映像。最适合不需要或永远不需要更新的事情。它重量大，速度慢并且难以操作；

二元

仅在数据库不可用于存储应用程序数据的地方。序列化（C ++）最简单。高度优化的二进制格式在速度和大小方面都将胜过其他所有格式。

没有银弹。在我的经验中：

纯文本作为存储介质是自动编号。在某些情况下，我什至会认为最好用.config文件覆盖它，其中我具有模式和类型安全性。似乎几乎总是需要类型安全和数据提取。纯文本使此过程成为噩梦。

XML：类型安全，数据验证，数据量小，在某些情况下我会使用它，因为.NET具有对对象的XML序列化的强大内置支持。

数据库：我的默认值。输入安全性，速度，交易，值得信赖，如果事情没有按计划进行，那么选择数据库作为存储介质就很难怪。

.zip是一种压缩格式，不确定是否适合持久性..？

二进制：仅在需要创建临时内存流时才使用二进制。与将数据按架构进行组织的DB或XML相比，Binary不会以查询能力的方式增加价值。

易用性是相对的，取决于您要具体完成什么。速度与我上面所说的音量相似。如果需要考虑文件大小并应用适当的规范化，我将通过zip或其他某种压缩格式对其进行压缩，但这是一个单独的过程。

我使用它们如下：

纯文本

如果该类别包括更复杂的格式（例如YAML或属性文件），那么对于您希望人们手工阅读和编辑的任何内容，它都是最佳选择。另一个巨大的优势是通过一个小的脚本（例如sed）修改它的简便性。

简单性和易用性无与伦比。当支持团队必须在远程计算机上配置某些内容（例如解决客户的问题），或者IT必须重新配置一堆运行您的软件的服务器时，他们会感谢您选择这种格式。它还可以帮助您避免编写一些一次性的软件来帮助他们。

XML格式

我在这里同意@Ingo －与纯文本XML不同，它很难通过脚本处理，并且手工imo也是一个噩梦。

但是，如果您具有结构复杂的数据，而YAML变得难以理解，并且仍然希望它可以被人类阅读和编辑，那么XML可能是最佳选择。

关系型数据库

当您拥有大量数据（这会使纯文本和XML变得繁琐）时，您可能仍然希望允许第三方通过SQL命令甚至GUI进行手动编辑的绝佳选择。

另一个优点是，管理内容的代码非常易读。@ Richard-Harrison在出色的回答中列出了许多其他优点。

NoSQL数据库

与RDBMS相比，优点之一是可通过分发实现可伸缩性，这可能与您的问题不太相关。可能更相关的优点是键值存储的简单性和无模式的灵活性（这是一个单词吗？）。当您发现自己破坏了关系范式时：只将blob存储到数据库中，通过键访问它们，然后通过代码对其进行处理，然后考虑使用此选项。某些选择（例如CouchDB）非常可移植，占地面积小，并且可以扩展，因此它们提供了MySQL和SQLite的良好非关系替代方案。

二元

二进制文件的优点是它既快速又紧凑。当唯一需要读取和修改文件的东西是程序，而数据不适合关系范式或速度时，则这可能是一个不错的选择。可能最适合媒体文件。

我应该指出的是，由于尚未进行初始设计时未考虑的原因，有时并不需要对程序数据进行简单访问。如今，我个人选择具有标准格式且需要由其他软件（例如音频，视频）进行编码/解码的文件以外的其他任何选项作为数据库选项。

注意：常见的误解是二进制文件是不透明的，因此更安全。没有额外的保护，事实并非如此-如果有人想入侵您的软件，然后简单地存储您的配置或二进制文件就不会阻止它们。

压缩档案

并不是上述的替代方案，而是一种额外的措施。

当您需要通过网络传输事物时，或者当您存储大量数据并希望节省空间时，此功能非常有用。请注意，这些天通常存储空间充裕，因此请考虑您的目标平台。

在当今几乎所有事物上都可以非常快地执行（摩尔定律，婴儿），因此不使用它的唯一原因是它增加了代码的复杂性。复杂性不高，但是仍然违反了KISS原则。对于需要手动或通过脚本编辑的配置文件而言，尤其麻烦。如果确实需要在此处节省空间，则可能应该使用数据库选项。

我将使用它们如下：

• 纯文本：该应用程序的结构化数据量较小（例如，名称/值对）。多个用户不能同时修改数据。
• XML：结构化数据较小，无法同时或频繁修改。
• 数据库：需要大型结构化数据或并发访问。在应用程序中必须进行查询和搜索。
• 二进制数据：我只会将其用于流对象。
• 压缩是一种压缩，可以添加为上述任何一项的另一个过程，但服务器上的数据库除外。

我听说XML结合了文本（难于处理/处理缓慢）和二进制（不可读）的最坏特征。