在 mysql 中处理大数据的最佳方式是什么？ 成员之间的跟进、通知等

如何解决在 mysql 中处理大数据的最佳方式是什么？ 成员之间的跟进、通知等

我有一个博客网站。我希望我的成员能够关注主题并相互关注。

Topics Table
id - title - content - tags - cat_id

Users Table
id - username - pass - nickname - mail - etc..

我有两种不同的方案。我找不到最佳解决方案

场景一

follows Table
id - user_id - topic_ids
1      1        1|2|3|4|5|...

notifications Table
id - user_ids - message
1    1|2|3|..   img_url|url|message..

notification_read Table
id - user_id - noti_id
1      1          1

在这种情况下，可以在没有太多列的情况下发送通知。感觉就像我获得了更好的性能，因为它占用的空间更少。

但是这种方法听起来像是会造成安全漏洞。 （使用没有字符限制的长文本（对于 topic_ids 和 user_ids））

场景 2

follows Table
id - user_id - topic_id
1      1        1
2      1        2
3      1        3
..     "       ..
..   same id   ..

notifications Table
id - user_id - read - msg_img - msg_url  -  msg
1       1       1     test.jpg   /test      New topic has been added in the category you follow.  
2       2       0     test.jpg   /test      New topic has been added in the category you follow.
3       3       0     test.jpg   /test      New topic has been added in the category you follow.
..     ..       ..    same img   same url   same msg

在这种情况下，它为每个关注者创建 1 行。如果 10000 人关注 1 个类别，它将为 1 个通知创建 10000 行。

为什么会有一个notification_read表？

我认为太多人无法同时编辑一栏。因此，我希望它是一个空间，我可以将阅读通知的人添加到不同的栏。 （如果我错了，请写。）

我应该继续哪个场景？

其实我想做的逻辑就像facebook。只有人不能添加主题。

话题跟进（新评论已写。） 会员跟进（评论一个话题。留下一个话题的声明。） 类别跟踪（此类别中添加了一个新视频。）

而且他需要能够在流程中看到它们。

除了第一种和第二种情况之外，可能还有其他想法，如果您能分享，我会很高兴。

解决方法

评论太长了。在 SQL 中，您永远不想在一个字符串中存储多个 id 列。原因如下：

• 值应使用适当的类型存储。数字不是字符串。
• 表之间的关系应该使用正确声明的外键关系。
• SQL 中的列旨在包含单个值，而不是多个值。
• SQL 的字符串解析功能很差。
• 必须解析字符串才能获取值会阻止优化器使用索引和分区以及其他优化策略。
• SQL 有一种表示列表的绝妙方法。它被称为表。

换句话说，您的第一个场景甚至不应该被认真地视为数据模型。