一般来说，如果实体之间有一对一或一对多的关系，则嵌入是很好的选择;如果实体之间有多对多的关系，则引用是很好的选择。

这与其说是科学，不如说是一门艺术。schema的Mongo文档是一个很好的参考，但是这里有一些事情需要考虑:

Put as much in as possible The joy of a Document database is that it eliminates lots of Joins. Your first instinct should be to place as much in a single document as you can. Because MongoDB documents have structure, and because you can efficiently query within that structure (this means that you can take the part of the document that you need, so document size shouldn't worry you much) there is no immediate need to normalize data like you would in SQL. In particular any data that is not useful apart from its parent document should be part of the same document. Separate data that can be referred to from multiple places into its own collection. This is not so much a "storage space" issue as it is a "data consistency" issue. If many records will refer to the same data it is more efficient and less error prone to update a single record and keep references to it in other places. Document size considerations MongoDB imposes a 4MB (16MB with 1.8) size limit on a single document. In a world of GB of data this sounds small, but it is also 30 thousand tweets or 250 typical Stack Overflow answers or 20 flicker photos. On the other hand, this is far more information than one might want to present at one time on a typical web page. First consider what will make your queries easier. In many cases concern about document sizes will be premature optimization. Complex data structures: MongoDB can store arbitrary deep nested data structures, but cannot search them efficiently. If your data forms a tree, forest or graph, you effectively need to store each node and its edges in a separate document. (Note that there are data stores specifically designed for this type of data that one should consider as well) It has also been pointed out than it is impossible to return a subset of elements in a document. If you need to pick-and-choose a few bits of each document, it will be easier to separate them out. Data Consistency MongoDB makes a trade off between efficiency and consistency. The rule is changes to a single document are always atomic, while updates to multiple documents should never be assumed to be atomic. There is also no way to "lock" a record on the server (you can build this into the client's logic using for example a "lock" field). When you design your schema consider how you will keep your data consistent. Generally, the more that you keep in a document the better.

对于您所描述的内容，我将嵌入注释，并为每个注释提供一个ObjectID id字段。ObjectID有一个嵌入的时间戳，所以你可以使用它而不是在你喜欢的时候创建。

如果我想编辑一个指定的评论，如何获得它的内容和它的问题?

您可以通过子文档进行查询:Content ': 'xxx'})。

这将返回整个Question文档。要编辑指定的评论，您必须在客户端上找到该评论，进行编辑并将其保存回DB。

一般来说，如果您的文档包含一个对象数组，您会发现需要在客户端修改这些子对象。

一般来说，如果实体之间有一对一或一对多的关系，则嵌入是很好的选择;如果实体之间有多对多的关系，则引用是很好的选择。

我知道这是相当古老的，但如果你正在寻找OP关于如何只返回指定注释的问题的答案，你可以像这样使用$(查询)操作符:

db.question.update({'comments.content': 'xxx'}, {'comments.$': true})

好吧，我有点晚了，但仍然想分享我的模式创建方法。

我有可以用一个词描述的所有事物的模式，就像在经典的OOP中那样。

E.G.

评论 账户 用户 博客 .．.

每个模式都可以保存为Document或Subdocument，因此我对每个模式都声明了这一点。

文档:

可以作为参考。(例如，用户做了一个评论->评论有一个“由”的参考用户) 是应用程序中的“根”。(例如，博客文章->有一个关于博客文章的页面)

子文档:

只能使用一次/绝不是参考。(例如，评论保存在博客文章中) 在应用程序中从来都不是“根”。(评论只在博客页面中显示，但页面仍然是关于博客的)