【问题标题】:MySQL: Embedded JSON vs tableMySQL:嵌入式 JSON 与表
【发布时间】:2023-03-07 09:50:01
【问题描述】:

我正在为视频制作项目管理应用程序设计数据库架构,并且正在努力解决如何保留一些嵌入式但不可重复的数据。在我参加的几门 CS 课程中,规范化关系数据库的一部分是识别可重复的块并将它们封装到自己的表中。如果我知道某个嵌入/嵌套数据块可能对记录是唯一的,该怎么办?

示例:video 记录有许多 shoot_locations。这些位置很可能永远不会重复。 shoot_locations 也可以包含多个shoot_times。用 JSON 表示,可能如下所示:

{
  video: {
    shoot_locations: [
      {
        name: "Bob's Pony Shack",
        address: "99 Horseman Street, Anywhere, US 12345",
        shoot_times: {
          shoot_at: "2015-08-15 21:00:00",
          ...
        }
      },
      {
        name: "Jerry's Tackle",
        address: "15 Pike Place, Anywhere, US 12345",
        shoot_times: {
          shoot_at: "2015-08-16 21:00:00"
          ...
        }
      }
    ],
    ...
  }
}

选项...

  1. shoot_locations 存储在 JSON 字段中(在 MySQL 5.7.8 中可用?)
  2. 为数据创建一个单独的表。
  3. 还有别的吗?

我觉得我应该将嵌入数据拆分到自己的表中,并为非关键元数据保存 JSON。

总结

存储非重复嵌入数据的最佳选择是什么?

【问题讨论】:

  • 很少,只有当它是回头客时。大多数视频拍摄都在独特的位置。
  • Hazzit 的正确答案如下。不要将位置视为标题-细节关系中的标题表,它只是视频的 1..n 属性。如果您想查询位置,并且因为您将其存储在数据库中,所以将它们放在位置表中。

标签: mysql database-design database-schema


【解决方案1】:

规范化数据库的原因之一是减少冗余(您的“可重复块”)

另一个原因是允许“向后”查询。如果您想知道哪个视频是在“15 Pike Place”拍摄的,那么您的 JSON 解决方案将失败(您将不得不诉诸顺序读取、解码 JSON,这违背了 RDBMS 的目的)

良好的经验法则:

  • 结构化数据 - 放入表格和列中
  • 可能是查询条件一部分的数据 - 放入表和列中
  • 您知道永远不会查询的非结构化数据 - 放入 BLOB、XML 或 JSON 字段中

如果有疑问,使用表格和列。一开始你可能不得不花一些额外的时间,但你永远不会后悔。人们一次又一次地后悔选择 JSON 字段(或 XML,就此而言)。我有没有提到“再次”?

【讨论】:

  • 2019年,还是这样吗?我偶然发现了一篇关于如何查询 JSON 字段的好文章:scotch.io/tutorials/working-with-json-in-mysql 你怎么看?
  • @Armand 是的,情况仍然如此。多年来,RDBMS 设计没有太大变化。解析一整列 JSON 总是可行的,但永远不会像将数据分配到自己的表那样结构化或高效。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-01-06
  • 2014-02-12
  • 1970-01-01
  • 2011-03-03
  • 1970-01-01
  • 2014-06-04
  • 2021-12-17
相关资源
最近更新 更多