在本文中，您将了解何时应考虑将 JSON 数据类型添加到表中以及何时应避免使用它们。

每天?分享?最新?软件?开发?，Devops，敏捷?，测试?以及?项目?管理?最新?，最热门?的?文章?，每天?花?3分钟?学习?何乐而不为?，希望?大家?点赞?，评论，加?关注?，你的?支持?是我?最大?的?动力?。下方抖音有我介绍自动化测试，以及google cloud 相关视频课程，欢迎观看。

在本文中，您将了解何时应考虑将 JSON 数据类型添加到表中以及何时应避免使用。

大多数关系数据库技术现在可以存储 JSON 数据并对其执行查询。将 JSON 数据类型引入关系数据库代表了一个转折点，并开辟了许多新的可能性。考虑到此功能的创新性，您可能会怀疑采用 JSON 数据是否是正确的选择。特别是，滥用 JSON 并失去关系模型的好处的风险很高。这就是为什么清楚地了解 JSON 数据可以为关系数据库带来的优缺点如此重要的原因。

在本文中，我们将探讨您需要了解的有关 JSON 列的所有信息，并告诉您何时最好依赖它们。

什么是 JSON？

JSON 代表 JavaScript Object Notation，代表一种轻量级、易于理解、人类可读的数据格式。在关系数据库中，JSON 数据类型是一种特殊的二进制或文本列，允许您以 JSON 格式存储数据。下面是一个 JSON 示例：

{
  "user": {
    "id": "1",
    "name": "Maria",
    "surname": "Williams",
    "hobbies": [
      {
        "name": "Tennis",
        "since": 1985
      },
      {
        "name": "Reading",
        "since": 1974
      }
    ]
  }
}

支持 JSON 的关系型数据库一般都带有 JSON 特有的函数和操作符，用于对这种数据类型进行查询和操作。例如，您可以在此处了解有关 PostgreSQL 在 JSON 数据方面提供的更多信息。

为什么关系数据库支持 JSON？

随着时间的推移，提供给用户的功能变得越来越复杂。因此，支持应用程序的正确数据结构不太可能是纯关系的。数据的重要性正在增加，并且表示它的方式也在相应地发展。开发关系数据库技术的人都知道这一点，并引入了 JSON 数据类型来支持对数据的新思维方式。

MySQL 从5.7 版开始引入 JSON 支持，该版本于 2015 年向公众开放。PostgreSQL 从 9.2 版开始支持 JSON 数据类型，于 2012 年发布。SQL Server 从 SQL Server 2016开始支持 JSON 。如您所见，大多数最流行的 RDBMS 都具有存储 JSON 数据的能力。这并不意味着关系模型正在消亡或不再有用。相反，它只是在进化和适应新的需求。

毕竟，关系数据库技术仅支持 JSON 作为一种数据类型。这意味着您可以向关系表中添加一个或多个 JSON 列。这不会从根本上破坏关系方法，而只是一种可能性，一种有用且强大的功能。

何时将 JSON 数据存储在关系数据库中

采用 JSON 数据类型并将 JSON 列添加到您的表中可以为您的关系模式带来几个优势。在完成下面定义的几个目标时尤其如此。

将 JSON 用于记录目的

您应该能够轻松阅读和理解您的日志数据，而 JSON 格式是存储它的好方法。因此，您应该考虑将日志数据转换为 JSON 格式并将其存储在 JSON 列中。此外，拥有一个包含日志数据的 JSON 列是一种通过查看一行来跟踪所发生情况的有效方法。使用这种方法，您不必定义新表、执行 JOIN 或花时间检索日志数据。

JSON 列对于记录数据的来源也很有用，尤其是在通过 API 导入数据时。考虑到 API 响应通常采用 JSON 格式，将它们存储在 JSON 列中是一种轻松的解决方案，不会丢失此数据并在需要时使用它。

存储权限和配置

并非所有用户都可以访问应用程序的相同功能和部分。同样，每个用户都可以根据他们的偏好配置您的应用程序。这是两种常见的情况，并且涉及随时间发生很大变化的数据。这是因为您的应用程序可能会发展，涉及新的配置、视图、功能和部分。因此，您必须不断更新您的关系模式以匹配新的数据结构。这需要时间和精力。

相反，您可以将权限和配置存储在直接连接到用户表的 JSON 列中。此外，对于您的权限和配置，JSON 是一种很好的数据格式。事实上，您的应用程序很可能以 JSON 格式处理这些数据。

避免高度嵌套数据的性能下降

如果性能是关键要求并且您的应用程序涉及高度嵌套的数据，则应考虑使用 JSON 列。当您必须将其作为一个整体使用时尤其如此。在关系方法中，您必须在多个表中构建数据。要检索它，您必须嵌套几个JOINs，这会使查询非常慢。

相反，通过将这些嵌套数据存储在 JSON 列中，您可以通过简单的SELECT查询来检索它。这将使您的数据检索过程更快，同时保持您的数据结构简单。

何时避免关系数据库中的 JSON 数据

有些人考虑将 JSON 数据类型用作反模式，并谨慎采用。原因是使用没有约束的格式（例如 JSON）会破坏您的关系模式。具体来说，您应该在以下情况下避免使用 JSON。

您不确定要在 JSON 列中存储哪些数据

JSON 格式很灵活，但这确实意味着您可以使用它来存储您想要的任何内容。在将 JSON 列添加到数据库之前，您必须明确定义它们的用途。否则，它们很可能成为垃圾抽屉。如果发生这种情况，对您的应用程序未来的后果可能是致命的。避免这种情况的唯一方法是为 JSON 列设计数据格式。

如果您不知道如何使用它们，请避免使用 JSON 列。有 JSON 列，但没有在其中存储 JSON 数据意味着在数据库级别没有数据验证，这可能导致应用程序级别没有一致性或完整性。

您不想处理复杂的查询

以 JSON 格式存储数据很酷，但不要忘记它会带来额外的成本和复杂性。其中之一是查询 JSON 列中的数据会导致看起来更复杂的查询。

以下是 PostgreSQL 中涉及 JSON 列的查询：

以下是在传统场景中等效查询的样子：

第二个更容易阅读和理解——如果 JSON 带来的好处不足以证明新查询的复杂性，请避免使用 JSON。

你有一个强类型的 ORM

在使用强类型 ORM技术映射数据库时，您可能会遇到涉及数据类型的问题。这是因为数据库级别的数据类型与应用程序级别的数据类型不同。当您想在应用程序级别处理存储在 JSON 列中的数据时，您有两种方法。

第一个是将 ORM 映射中的 JSON 列定义为字符串，然后将它们转换为对象。否则，如果您的 ORM 支持此选项，您可以使用自定义结构化类型映射列。无论哪种情况，应用程序或 ORM 都必须在后台执行数据转换。这是有代价的，并且可能会影响后端性能。

结论

数据已经发展，关系模型可能不再足以有效地表示数据。这就是为什么一些最流行的关系数据库技术的供应商引入了使用 JSON 数据类型来处理非结构化数据的方法。多亏了这一点，您可以将NoSQL 的优势引入到您的关系数据库中。在这里，我们研究了 JSON 数据类型是什么，为什么引入它，以及何时使用或避免使用它。请务必关注我们的博客以获取更多内容，直到下一次。