MongoDB中多类型DBRef数组的重构方案及性能疑问

先说说为什么DBRef被认为低效 #

• DBRef是一种标准化的跨集合引用格式，但MongoDB不会自动解析它，你得自己写代码处理集合名和ID的关联查询，和手动存集合名+ID没区别，还多了不必要的格式开销。
• 每次查询DBRef都得单独请求目标集合，而且没法用$lookup做批量关联（因为DBRef的集合名是动态的，$lookup要求固定集合名），一旦数组里有大量DBRef，就会触发N+1次查询，效率极低。
• 没有类型校验机制，DBRef里的集合名写错了很难排查，增加维护成本。

重构方案推荐 #

方案1：拆分多个独立的ObjectId数组 #

把原来的子项数组拆成vegetables、fruits、meats三个数组，每个数组只存对应集合的ObjectId，示例文档结构：

{
  "_id": ObjectId("60d21b4667d0d8992e610c85"),
  "vegetables": [ObjectId("60d21b4667d0d8992e610c86"), ObjectId("60d21b4667d0d8992e610c87")],
  "fruits": [ObjectId("60d21b4667d0d8992e610c88")],
  "meats": []
}

优点：

• 结构清晰，一眼就能看出关联的子项类型
• 查询时可以针对需要的集合单独做$lookup批量关联，效率比DBRef高很多
• 容易做数据校验，能确保每个数组里的ID都属于对应的集合

缺点：如果后续新增子项类型（比如seafood），需要修改文档结构添加新数组字段。

方案2：用嵌入式文档存储「集合名+ID」组合 #

保留单个子项数组，但每个元素是包含collection和_id的文档，示例结构：

{
  "_id": ObjectId("60d21b4667d0d8992e610c85"),
  "items": [
    { "collection": "vegetable", "_id": ObjectId("60d21b4667d0d8992e610c86") },
    { "collection": "fruit", "_id": ObjectId("60d21b4667d0d8992e610c88") }
  ]
}

优点：

• 扩展性强，新增子项类型不需要修改文档结构，直接在items里加新对象就行
• 可以通过聚合操作按collection分组，再分别关联对应的集合（代码层面可以批量查询不同集合的ID，减少请求次数）

缺点：查询时的关联逻辑复杂度略高于方案1，但比DBRef灵活得多。

总结 #

如果你的子项类型固定（目前只有vegetable、fruit、meat，短期内不会新增），方案1更符合MongoDB的惯用设计，结构清晰且查询高效；如果子项类型可能频繁新增，方案2的扩展性会更合适。

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