mongodb：这就是我应该规范化嵌入对象的地方吗？

我有一个包含

EmbeddedThing

s的

Parent

s集合，每个

EmbeddedThing

包含对创建它的

用户的引用

UserCollection: [
  {
    _id: ObjectId(…),
    name: '…'
  },
  …
]

ParentCollection: [
  {
    _id: ObjectId(…),
      EmbeddedThings: [
      {
        _id: 1,
        userId: ObjectId(…)
      },
      {
        _id: 2,
        userId: ObjectId(…)
      }
    ]
  },
  …
]

我很快意识到，我需要为给定的用户获取所有
EmbeddedThing
s，这是我使用map/reduce实现的：

"results": [
  {
    "_id": 1,
    "value": [ `EmbeddedThing`, `EmbeddedThing`, … ]
  },
  {
    "_id": 2,
    "value": [ `EmbeddedThing`, `EmbeddedThing`, … ]
  },
  …
]

这是我真正应该将
EmbeddedThing
规范化到它自己的集合中的地方，还是我应该保留map/reduce来完成这项工作？也许是其他的设计

如果有帮助的话，这是为了让用户在所有
父级
s中看到他们的
EmbeddedThing
s列表，而不是针对某些报告/聚合任务（这让我意识到我可能做错了）

谢谢
 “嵌入还是不嵌入：这是个问题”：

我的规则是：


如果嵌入对象仅在父对象的上下文中有意义，则嵌入。例如，
OrderItem
没有
Order
就没有意义
根据性能要求嵌入。阅读完整的文档树非常便宜（而不是必须进行多个查询并以编程方式连接它们）

您应该查看您的访问模式。如果每秒加载
ParentThing
数千次，并且每周加载
User
一次，那么map reduce可能是一个不错的选择。用户查询将很慢，但对于您的应用程序来说可能还可以

另一种方法是进一步去规范化。也就是说，当您添加嵌入式对象时，将其同时添加到父对象和用户


优点：查询速度很快
缺点：代码复杂。写入量加倍。潜在的同步丢失（您在一个位置更新/删除，但忘记在另一个位置执行）
我喜欢mongodb的灵活性，但我真的讨厌“视情况而定”部分，因为我必须考虑额外的东西：）因为这是一个全新的项目，我只能猜测访问模式。也因为它是新的，我关注的是开发的易用性，而不是速度。听起来我现在不应该去规范化它！