MongoDB 数据建模

解决什么问题

MongoDB 数据模型常见误区是过早追求规范化，把强关联字段拆成多集合，导致首页列表和详情页反复 $lookup；或者把大量评论嵌入文章文档，造成文档膨胀。这个技能面向开发者在设计或重构阶段，把查询路径、写入频率和文档大小作为决策输入，避免上线后再推倒重来。

核心工作流

技能先判断业务是否适合 MongoDB：文档结构灵活、读多写少、JSON 与前端天然匹配、需要水平扩展的场景更合适；强跨文档事务、复杂多表 JOIN、固定 schema 的报表系统应优先考虑 PostgreSQL。随后按“一起读、一起写”原则处理建模决策：一对一关系倾向嵌入，一对少可嵌入，一对多通常独立集合加引用；如果读多写少且引用集合不大，可使用 Extended Reference 冗余 author_name，也可用 Computed Pattern 缓存 comment_count。最后围绕查询路径给出索引与聚合方案，例如 articles: { created_at: -1, status: 1 }、comments: { article_id: 1, created_at: -1 }，并优先用 $lookup、$project 减字段，详情页用两次查询替代 $lookup + $unwind。

适用边界

该技能适合新项目选型、已有集合变慢、TB 级分片与聚合管道优化；不适合严格 ACID 跨文档事务、复杂 OLAP 或多表 JOIN。输出更像架构评审清单，不替代具体业务约束下的压测与容量评估。