如何在MongoDB中最优建模无界多对多关系？是否有替代方案？

针对你提到的用户-帖子归属、帖子-点赞这两类无界关系，结合MongoDB的特性，给出实际可落地的方案，同时纠正关于“关联表”的误区：

一、用户与帖子的归属关系（用户拥有无限帖子） #

这本质是一对多关系，但因为帖子数量无界，嵌入用户文档（把posts数组存在user里）肯定不可行——会很快触及MongoDB单文档16MB的上限，且查询时加载冗余数据。

最优方案：

• 单独创建posts集合，每个帖子文档里存储owner_user_id字段（关联用户的_id）。
• 查询某用户的所有帖子时，直接执行db.posts.find({owner_user_id: ObjectId("用户ID")})，给owner_user_id建索引后性能拉满。
• 如果需要频繁展示用户的最新帖子（比如主页显示最近10条），可以在users文档里嵌入一个recent_posts数组，只存最新10条帖子的_id和核心信息（标题、发布时间），这样查用户主页时不用全量扫描posts集合，提升前端加载速度。

二、帖子与点赞的无界多对多关系 #

这是典型的无界多对多，这里有两种可靠方案，按需选择：

方案1：中间集合（关联表）——首选方案 #

创建post_likes集合，每个文档结构如下：

{
  _id: ObjectId("xxx"),
  post_id: ObjectId("帖子ID"),
  user_id: ObjectId("点赞用户ID"),
  liked_at: ISODate("2024-05-20T12:00:00Z")
}

• 优势：完全支持无界扩展，能快速实现以下查询：
  • 查某帖子的所有点赞用户及点赞时间：db.post_likes.find({post_id: 帖子ID}).sort({liked_at: -1})
  • 查某用户点赞过的所有帖子：db.post_likes.find({user_id: 用户ID}).sort({liked_at: -1})
  • 支持扩展属性（比如点赞时的设备信息、是否取消过点赞）
• 关键优化：给{post_id: 1, user_id: 1}建唯一索引，防止同一用户重复点赞；给user_id单独建索引，加速用户点赞记录的查询。

误区纠正：MongoDB不是禁止用关联表，而是不鼓励在不需要关联的场景硬套关系型数据库的模式。对于无界多对多且需要保留关系附加信息的场景，中间集合是非常可靠的解决方案，在实际生产中被广泛使用。

方案2：原子计数+索引查询（适合极简需求） #

如果你的需求只是统计帖子点赞数和快速判断用户是否点赞某帖子，可以用这个轻量化方案：

• 在posts文档中增加like_count字段，点赞时用原子操作更新：db.posts.updateOne({_id: 帖子ID}, {$inc: {like_count: 1}})
• 依然保留post_likes集合，但只用来存user_id和post_id的关联（无需liked_at等字段），给{user_id: 1, post_id: 1}建唯一索引。判断用户是否点赞时，只需执行db.post_likes.findOne({user_id: 用户ID, post_id: 帖子ID})，存在则说明已点赞。
• 注意：这个方案仅适合不需要查询“用户点赞历史”或“帖子点赞列表”的场景，否则还是用方案1。

三、核心原则 #

MongoDB建模的核心是贴合查询模式，而不是教条遵循“不用关联表”的说法：

• 嵌入方案只适合有界的小批量关联（比如用户的最近几条帖子），无界场景绝对不要用。
• 中间集合是无界多对多关系的可靠选择，只要做好索引优化，性能完全够用。
• 轻量化方案适合极简需求，能减少查询开销。

内容的提问来源于stack exchange，提问作者mkkl