在 mysql 中处理大数据的最佳方式是什么？ （成员之间的跟进、通知等）
What is the best way to work with big data in mysql? (Follow-up between members, notifications etc.)
我有一个博客网站。我希望我的成员能够关注主题和彼此。
Topics Table
id - title - content - tags - cat_id
Users Table
id - username - pass - nickname - mail - etc..
我有 2 种不同的场景 mind.I 找不到最佳解决方案
场景一
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
在这种情况下，无需太多列即可发送通知。感觉我获得了更好的性能，因为它占用更少 space.
但这种方法听起来会造成安全漏洞。 （使用没有字符限制的长文本（对于 topic_ids 和 user_ids））
场景二
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
在这种情况下，它会为每个 follower.If 10000 人关注 1 个类别创建 1 行，它将为 1 条通知创建 10000 行。
为什么会有notification_read的table？
我认为太多人无法同时编辑一个栏目 time.For 因此，我希望它成为一个 space 可以将阅读通知的人添加到不同栏目的地方。 （如果我对此有误，请写信。）
我应该继续哪个场景？
其实我想做的逻辑就像facebook。只有人不能添加主题。
话题跟进（写了新评论。）
会员跟进（评论了一个主题。就一个主题发表了声明。）
类别跟踪（已将新视频添加到此类别。）
并且他需要能够在流程中看到它们。
除了第一种和第二种情况之外，可能还有其他想法，如果您能分享，我将很高兴。
评论太长了。在 SQL 中，您 永远不会 想要在一个字符串中存储多个 id 列。原因如下：
- 应使用适当的类型存储值。数字不是字符串。
- table 之间的关系应使用正确声明的外键关系。
- SQL 中的列旨在包含单个值，而不是多个值。
- SQL 字符串解析功能较差。
- 必须解析字符串以获取值会阻止优化器使用索引和分区以及其他优化策略。
- SQL 有一种很好的表示列表的方式。它被称为 table.
换句话说，您的第一个场景甚至不应该被认真地视为数据模型。
我有一个博客网站。我希望我的成员能够关注主题和彼此。
Topics Table
id - title - content - tags - cat_id
Users Table
id - username - pass - nickname - mail - etc..
我有 2 种不同的场景 mind.I 找不到最佳解决方案
场景一
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
在这种情况下，无需太多列即可发送通知。感觉我获得了更好的性能，因为它占用更少 space.
但这种方法听起来会造成安全漏洞。 （使用没有字符限制的长文本（对于 topic_ids 和 user_ids））
场景二
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
在这种情况下，它会为每个 follower.If 10000 人关注 1 个类别创建 1 行，它将为 1 条通知创建 10000 行。
为什么会有notification_read的table？
我认为太多人无法同时编辑一个栏目 time.For 因此，我希望它成为一个 space 可以将阅读通知的人添加到不同栏目的地方。 （如果我对此有误，请写信。）
我应该继续哪个场景？
其实我想做的逻辑就像facebook。只有人不能添加主题。
话题跟进（写了新评论。） 会员跟进（评论了一个主题。就一个主题发表了声明。） 类别跟踪（已将新视频添加到此类别。）
并且他需要能够在流程中看到它们。
除了第一种和第二种情况之外，可能还有其他想法，如果您能分享，我将很高兴。
评论太长了。在 SQL 中，您 永远不会 想要在一个字符串中存储多个 id 列。原因如下：
- 应使用适当的类型存储值。数字不是字符串。
- table 之间的关系应使用正确声明的外键关系。
- SQL 中的列旨在包含单个值，而不是多个值。
- SQL 字符串解析功能较差。
- 必须解析字符串以获取值会阻止优化器使用索引和分区以及其他优化策略。
- SQL 有一种很好的表示列表的方式。它被称为 table.
换句话说，您的第一个场景甚至不应该被认真地视为数据模型。