JSON 服务器端数据存储文件有哪些缺点？

Question

我正在寻找 SQL 的替代数据存储方法（也就是说，我确实不想想要使用 SQL，即使用于查询）并且遇到了一个很少有基于 JSON 的。和做数据库工作的朋友交谈，他们说我不应该考虑这些，但不会详细说明。 使用 JSON 作为数据存储文件格式有哪些潜在的（和实际的）缺点？

---

我认为 JSON 会比 SQL 更好，原因如下：

1. JSON 是严格定义的，没有风格（Oracle、Microsoft、MySQL 等）
2. 自从 Google 开始制作 Chrome 以来，JS 解释器已经使读取、解析和输出 JS（以及 JSON）成为一个非常 快速且简单的过程。
3. 数据库输出可以是纯 JSON，消除了对浏览器等中间人解释器的需求。

其中...

Answer 1

即使使用关系数据库，数据完整性（或引用完整性）仍然很困难，因为行通常带有时间戳。因此，通常不强制执行外键。当发生行更新时，您有 2 个选择。首先，“忘记”以前的版本。其次，更新原始行并将以前的版本复制到带有时间戳的“非关系”历史表中，其中外键无用。大多数业务数据都需要更新。在关系数据库中维护参照完整性的功能对于这种类型的业务数据（代表大多数企业数据）是无用的。 所需要的是一个时间数据库，或一个抽象层，它根据时间上下文向用户呈现行的适当版本。理想情况下有两个维度，即交易时间和业务时间（又名有效时间）。

Answer 2

我想你可能想看看 NO-SQL 数据库： https://en.wikipedia.org/wiki/NoSQL

如果您喜欢使用类似 JSON 的数据，那么我个人使用的一种是 MongoDB。

我没有将它用作我的应用数据的主要/单一来源，但仅用于次要目的。但是，我想，您也可以尝试将它用作您的主要数据存储（我想很多人都这样做）。

我尝试过并且非常满意的是使用 C# 的 MongoDB，并使用 MongoVue 作为 GUI 应用程序来执行查询和与数据库交互。我对 MongoVUE 不是很满意，但在当时看来它是最好的选择。

但是，SQL DB 非常擅长定义数据中的关系。例如。从表 B 上的条目中引用表 A 上的条目，等等。使用这些关系，您可以连接表并做许多有趣的事情。我认为，你也可以在这个领域获得一些经验。

MongoDB 不是为定义关系而构建的（据我所知）。它具有“文档”的概念，您可以在其中以类似 JSON 的格式（带有嵌套的键/值）存储信息。您可以查询文档，但加入似乎是在绕过其正常用法：How do I perform the SQL Join equivalent in MongoDB? 此外，在 MongoDB 中使用关系时确保数据一致性（以真正可靠的方式）对我来说似乎是不可能的。但即使我错了并且有可能，实现它也比使用 SQL DB 难 10 倍。

但是您可以查看 WikiPedia 中的列表，可能有比 MongoDB 更好的替代方案。

但您也可以使用纯 JSON，无需数据库系统。

因此，总的来说，类似 JSON 的存储（至少）存在以下问题：

• 不擅长定义和利用关系
• 使用关系时，数据完整性（或更可能是引用完整性）很难实现。
• 如果您没有使用良好的数据库系统，而只是将 JSON 转储到一个文件中，那么当该文件变得太大时，您将遇到性能问题。想象一下查询一个 1GB 的 JSON 编码的对象数组来获取你想要的对象。您必须将整个数组加载到内存中，遍历整个数组（因为您将没有索引）然后（如果您没有用完内存并且您的连接 - 使用网络时 - 没有过期）会得到一个结果。大多数像 MongoDB 这样的 NO-SQL 数据库和大多数 SQL 数据库都没有这样的问题（至少在合理的数据量内）。它们经过微调，支持索引、引用、权限、角色，您还可以在 DB 级别定义执行代码（如触发器和存储过程）。当然，它们更复杂，但大多数时候可能需要这种复杂性才能实现最终结果。

Answer 3

JSON 或 JavaScript Object Notation 是一种开放标准格式，它使用人类可读的文本来传输由属性-值对组成的数据对象。它主要用于在服务器和 Web 应用程序之间传输数据，作为 XML 的替代方案。

你真的更多的是看database vs flat-file storage之间的比较。