MongoDB多类型对象关注/取关Schema设计及取关追踪方案咨询

嘿，这个问题问到点子上了——在做关注/取关功能时，追踪行为轨迹和维护当前状态的平衡确实是个关键设计点。我来给你拆解两种主流方案，以及各自的适用场景：

方案1：添加deleted字段（软删除模式） #

这是你最初设想的思路：在现有Schema基础上新增一个deleted字段（Date类型，默认null）。用户关注时创建记录，deleted保持null；用户取关时，更新这条已有记录，把deleted设为当前时间。

优点 #

• 数据更紧凑：每条关注关系仅对应一条记录，查询当前关注状态时只需过滤deleted: null，性能高效。
• 单条记录完整保留生命周期：能直接看到某条关注的创建时间和取关时间（如果有的话）。

缺点 #

• 无法追踪多次往复操作：如果用户取关后又重新关注，旧记录的deleted会被覆盖，之前的取关历史就丢失了。
• 扩展性有限：如果后期业务需要分析用户的关注行为波动（比如反复关注取关某个对象的频次），这个方案满足不了需求。

方案2：每次操作创建新记录（事件流模式） #

换个思路：不管是关注还是取关，都新增一条独立记录，用一个action字段标记操作类型（比如follow或unfollow）。

优点 #

• 完整保留行为轨迹：用户每一次关注/取关操作都有记录，完美支持行为分析、用户画像、运营复盘等场景。
• 并发友好：所有操作都是插入，不会出现多个请求更新同一条记录的冲突问题。

缺点 #

• 数据量增长更快：随着用户操作次数增加，记录数会线性增长，但MongoDB对海量数据的处理能力很强，只要索引合理，这个问题基本可以忽略。
• 查询当前状态稍复杂：要判断用户是否关注某个对象，需要取该用户+内容组合下的最新记录，看action是follow还是unfollow（可以用聚合查询实现）。

如果你的业务只需要维护当前关注状态，以及记录单次取关时间，方案1足够轻量且实用。调整后的Schema如下：

{
  created: { type: Date, default: Date.now },
  deleted: { type: Date, default: null }, // 取关时赋值为当前时间
  contentType: { type: String, required: true, trim: true }, // 建议设为必填，明确区分关注对象类型
  contentId: { type: Schema.ObjectId, required: true },
  user: { type: Schema.ObjectId, ref: 'User', required: true }
}

这里建议把contentType设为必填——毕竟你要支持多类型对象，必填能避免数据缺失导致的业务逻辑混乱。同时记得给{ user: 1, contentType: 1, contentId: 1 }加唯一索引，防止同一个用户重复关注同一个对象。

如果你的业务需要追踪用户完整的关注行为历史（比如做用户偏好分析、运营活动效果复盘），方案2是更优选择。对应的Schema示例：

{
  timestamp: { type: Date, default: Date.now }, // 用timestamp更贴合事件时间的语义
  action: { type: String, required: true, enum: ['follow', 'unfollow'] }, // 明确标记操作类型
  contentType: { type: String, required: true, trim: true },
  contentId: { type: Schema.ObjectId, required: true },
  user: { type: Schema.ObjectId, ref: 'User', required: true }
}

查询当前关注状态的聚合查询示例：

db.followEvents.aggregate([
  { $match: { 
      user: ObjectId("目标用户ID"), 
      contentId: ObjectId("目标内容ID"), 
      contentType: "user" // 替换为实际类型，比如"post"或"page"
    } },
  { $sort: { timestamp: -1 } }, // 按时间倒序取最新记录
  { $limit: 1 },
  { $project: { isFollowing: { $eq: ["$action", "follow"] } } }
])

记得给{ user: 1, contentType: 1, contentId: 1, timestamp: -1 }建复合索引，能大幅提升这个查询的性能。

不管选哪种方案，核心索引都不能少：围绕user、contentType、contentId这几个字段建索引，因为大部分业务查询都是“某用户关注了哪些对象”或者“某对象被哪些用户关注”。

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