Mysql用户源，包含大量帖子

我有三个mysql表：

用户-包含用户详细信息

帖子-包含帖子详细信息

post_用户-包含每个用户应访问的帖子（用于阅读目的）

我真的需要pivot表，因为有很多逻辑决定用户是否能够阅读文章

此解决方案存在一些问题：

第一个问题是，我有超过200k个活动用户，因此每次创建一篇新文章时，都会将200k行插入透视表（post_user）

第二个问题是为每个用户获取帖子时。它有点慢，所以我尝试使用Redis为每个用户存储查询结果，这样我就不必从那个巨大的表中获取结果

数据库大小的增长速度非常快：/

---

为每个

帖子添加200000行--Yikes！这本身就是一个糟糕设计的标志

听起来“层次树”的ID可以作为“角色”或“组”使用

不管它叫什么，实现都是一样的：两个关系表：


用户组（例如，用户位于树的哪个部分）
组帖子（哪些组可以阅读特定帖子）

两者都是多：多，应该使用性能指南来实现。请注意，
id
（对于映射表）是无用的，可能会影响性能。
“Pivot”在这里是一个错误的术语。通常使用“连接器”或“关系”表。Pivot更多的是一种功能，其中行内值被透视到列标题中，其他字段以某种方式聚合到新标题值下。我不明白为什么表
post\u user
充当“特权”表。除此之外，所有用户都拥有对所有帖子的“读”权限，创建一个黑名单表，在其中“禁止”一些用户访问帖子，不是更好吗？这将需要更少的数据库空间。至于这个解决方案，我同意这似乎是一个非常糟糕的设计。用户不应该访问这样的帖子。相反，请考虑创建一个包含用户可能参与的角色的<代码>角色< /C> >（一个可能是“读取所有帖子”）。然后是映射的
user\u角色
表。通过创建
perm
表和
role\u perm
表，可以将
user
映射到
role
，并且
role
具有
权限
其中一个可能是“读取所有帖子”。然后相应地更新代码。这将真正帮助你控制这一切。还有很多语言库实现了这种逻辑，所以你不必自己动手。如果信息真的很重要，应该在你的问题中。每个用户可以被分配到一个“组”（IOW troup等）。这些组将存储在树中的组织表中。然后是一个简单的查询，确定用户可以阅读哪些帖子。