mysql - 使用 JSON 而不是规范化数据，这种方法是否正确？

Question

有微博帖子，以及与之相关的投票/表情，都在 MySQL innoDB 表中。 有两种类型的页面的要求:

(A) 包含许多微博的列表页面以及他们在单个页面上的投票计数/表情符号计数(比如 25)。

例如

THE GREAT FUNNY POST

Not so funny content in a meant to be funny post. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus euismod consequat pellentesque. .....READ MORE....

(3) likes, (5) bored, (7) smiled

. + 同一页面上有 24 个更多帖子。

(B) 固定链接页面，包含一个带有详细投票+投票计数/表情符号的微博。

THE GREAT FUNNY POST

Not so funny content in a meant to be funny post. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus euismod consequat pellentesque. Quisque viverra adipiscing auctor. Mauris ut diam risus, in fermentum elit. Aliquam urna lectus, egestas sit amet cursus et, auctor ut elit. Nulla tempus suscipit nisi, nec condimentum dui fermentum non. In eget lacus mi, ut placerat nisi.

(You, Derp and 1 more like this), (5) bored, (7) smiled

第一种方法:

表#1:

post_id | post_content | post_title | creation_time 

用于存储投票、点赞、表情符号的表#2:

action_id | post_id | action_type | action_creator | creation_time

显示一页帖子或单个帖子。查询第一个表以获取帖子， second 被查询以获取与帖子相关的所有操作。每当投票等完成时，都会在 post_actions 表中插入。

第二种方法:

表#1:

post_id | post_content | post_title | creation_time | action_data 

action_data 可以是 { "likes": 3,"smiles":4 ...}

表#2:

action_id | post_id | action_type | action_creator | creation_time

要显示一页帖子，只查询第一个表以获取帖子和操作数据， 要显示带有详细操作的单个帖子，查询第二个表以获取与帖子相关的所有操作。每当投票等完成时，都会向 post_actions 表和 action_data 进行插入 更新表#1 的字段以存储更新的计数。

假设有 10 万个帖子和 10 次操作，即创建了 100 万个或更多操作。 方法#2 有好处吗？除了必须读取、修改和更新 JSON 信息之外，它还有什么缺点吗？ 无论如何，是否可以遵循并进一步改进方法#2？

根据反馈添加更多信息:

1. Python 脚本将读取、写入数据。
2. MySQL 数据库服务器将不同于网络服务器。
3. 由于帖子创建而导致的写入量很低，即每天 10000 个。但由于操作而导致的写入次数可能更高，假设由于投票、点赞、表情符号等操作，每秒最多写入 50 次。
4. 我关心的是两种方法的读/写性能比较和第二种方法的问题，以及它将来可能存在的不足。

Answer 1

我建议要么将所有喜欢/投票数据(聚合的和原子的)存储在表 1 中并完全丢弃表 2要么使用 2 个没有聚合数据的表，同时依赖于 JOIN 语法、巧妙的查询和良好的索引。

为什么？因为否则在发表评论/投票/点赞时，您将一直查询并写入两个表。假设每个帖子有 10 个 Action 仅用于显示交互，我真的会将其全部存储到一个表中，也许为每种 Action 制作一个额外的列。您可以在数组上使用 JSON 或简单地使用 serialize()，这应该会更快一些。

您最终选择哪种解决方案将在很大程度上取决于您获得的操作数量以及您希望如何使用它们。使用解决方案 1 可以轻松获取 1 个帖子的所有操作，而且速度非常快，但在内部搜索会很麻烦。另一方面，解决方案 2 占用更多空间，需要仔细编写查询和索引。