MySQL:嵌入式JSON vs表

Tod*_*ter 9 mysql database-design database-schema

我正在为视频制作项目管理应用程序设计数据库架构,并且在如何保留一些嵌入但不可重复的数据方面苦苦挣扎.在我参加的几个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"
          ...
        }
      }
    ],
    ...
  }
}
Run Code Online (Sandbox Code Playgroud)

选项...

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

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

摘要

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

Haz*_*zit 12

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

另一个原因是允许"向后"查询.如果您想知道哪个视频是在"15 Pike Place"拍摄的,那么您的JSON解决方案将失败(您将不得不求助于顺序读取,解码JSON,这会破坏RDBMS的目的)

好的经验法则:

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

如有疑问,请使用表格和列.你最初可能不得不花费一些额外的时间,但你永远不会后悔.人们已经一次又一次地对JSON字段(或XML)的选择表示遗憾.我再说一次吗?

  • @Armand 是的,情况仍然如此。多年来,RDBMS 设计并没有发生太大变化。解析一整列 JSON 始终是可行的,但永远不会像将数据分配到自己的表那样结构化或高效。 (2认同)