我对文档导向型数据库非常感兴趣，想要尝试一下 MongoDB。于是我开始了一个相当简单的项目（一个问题追踪器），但是在思考非关系型数据库时遇到了困难。
我的问题：
我有两个相关联的对象（例如 issue = {code:"asdf-11", title:"asdf", reporter:{username:"qwer", role:"manager"}} - 这里有一个与问题相关的用户）。我应该创建另一个文档'用户'并在'问题'文档中引用它的ID（像关系型数据库一样），还是应该将所有用户数据留在子文档中？
如果我在一个文档中有多个对象（子文档），我能否在单个查询中更新它们全部？
issue = {code:"asdf-11", title:"asdf", reporter:{username:"qwer", role:"manager"}}
db.tickets.aggregate({$match:{"reporter.username":"qwer"}},{$group:{_id:'$reporter.username', c:{$sum:1}}}) 另外：“如果您嵌入文档，则无法在单个查询中更新所有文档。”是的，您可以进行原地更新；问题在于如果用户重复，更新将在多个主文档之间重复，但即使如此，它也是一个原地$set更新，您不必加载每个主文档。 - SammayeMongoDB和其他“NoSQL”产品的美妙之处在于没有需要设计的模式。我使用MongoDB，我喜欢它，因为不需要编写SQL查询和糟糕的JOIN查询！所以来回答你的两个问题。
1 - 如果您创建多个文档，则需要对数据库进行两次调用。并不是说这是一件坏事，但如果您可以将所有内容放入一个文档中，为什么不这样做呢？我记得以前使用MySQL时，我会创建一个“博客”表和一个“评论”表。现在，我将评论附加到同一集合（也称为表）中的记录中，并继续构建它。
2 - 是的...
Nigel 的角色为 MD（如之前所示），并将工单状态更改为已完成：db.tickets.update({'reporter.username':'Nigel'},{$set:{'reporter.role':'MD', status: 'completed'}})
因此，在这种情况下，单个文档模式确实使CRUD更容易。
需要注意的一件事是，根据您的英语，您不能使用位置运算符更新根文档下的所有子文档。相反，它只会更新找到的第一个子文档。
再次希望这有意义，我没有漏掉任何内容。祝好运！
这里我有一个与问题相关的用户。我应该创建另一个名为“用户”的文档，并通过其ID在“问题”文档中引用它（就像在关系数据库中一样），还是应该将所有用户数据放在子文档中？
这是一个值得考虑的问题，在继续之前需要一些背景知识。
首先要考虑的是问题的大小：
issue = {code:"asdf-11", title:"asdf", reporter:{username:"qwer", role:"manager"}}
这个文本并不是很大，而且由于您不再需要reporter信息（该信息将在根文档中），因此它可能会更小，但是问题从来都不是那么简单。例如，如果您查看MongoDB JIRA：https://jira.mongodb.org/browse/SERVER-9548（作为证明我的观点的随机页面），一个“票”的内容实际上可能相当可观。
唯一能够从嵌入式票据中获得真正好处的方法是，如果您可以将所有用户信息存储在单个16 MB的连续存储块中，这是BSON文档的最大大小（目前由mongod强制执行）。
我认为您无法将所有票据存储在单个用户下。
即使您将票据缩小到一个代码、标题和描述，您仍然可能遭受由于 MongoDB 中文档的定期更新和更改所导致的“瑞士奶酪”问题，就像这个：http://www.10gen.com/presentations/storage-engine-internals 是我所说的内容的好参考。code和title，那么是的，您可以将票据作为子文档存储在根用户中而不会遇到太多问题，但是，这取决于赏金任务的具体要求，目前还未提及。db.users.update({user_id:uid,'tickets.code':'asdf-1'}, {$set:{'tickets.$.title':'Oh NOES'}})
需要注意的是，您只能使用位置操作符一次更新一个子文档。因此，这意味着您不能在单个原子操作中将单个用户的所有票据日期更新为未来5天。
至于添加新票据，那很简单：
db.users.update({user_id:uid},{$push:{tickets:{code:asdf-1,title:"Whoop"}}})
是的，根据您的查询，您可以非常简单地在单个调用中更新整个用户数据。
这是一个相当长的答案，希望我没有漏掉任何东西，希望能帮到您。
在面向文档的数据库中进行模式设计一开始可能会感到困难，但是我使用Symfony2和MongoDB构建我的创业公司时发现，80％的时间就像关系型数据库一样。
首先，将其视为普通的数据库：
要开始，只需像使用关系型数据库一样创建模式：
每个实体都应该有自己的集合，特别是如果您需要对其中的文档进行分页。
（在Mongo中，您可以在某种程度上对嵌套的文档数组进行分页，但功能有限）
然后只需删除过于复杂的规范化：
嵌入式文档：
只有在以下情况下使用嵌入式文档：
addressInfo、billingInfo）[ name: "Sport", parent: "Hobby", page: "/sport" ]）不要在以下情况下使用嵌入式文档：
在集合中重复值并预先计算计数：
如果您需要在 where 条件中查询每个值，则从一个集合复制一些列/属性值到另一个集合中。 （请记住，没有 join）
例如：在 Ticket 集合中还要放置作者姓名（不仅是 ID）
此外，如果您需要计数器（用户打开的票数，按类别分类等），请预先计算它们。
嵌入式引用：
当您拥有一个一对多或多对多的引用时，请使用带有引用文档ID列表的嵌入式数组（请参见 MongoDB DB Ref）。
如果引用文档被删除，您需要再次使用事件来删除ID。 （如果您使用Doctrine ODM，则有一个扩展程序： 引用完整性）
这种引用由Doctrine ODM直接管理： 多个引用
修复错误很容易：
如果您在模式设计中发现错误，只需几行JavaScript代码直接在Mongo控制台中运行即可轻松解决。
（存储过程变得简单：无需复杂的迁移脚本）
警告：不要使用Doctrine ODM Migrations，否则您将会后悔。
MongoDBRef是一种特殊类型的引用，大多数情况下仅使用OjbectId会占用更少的空间。 - Sammaye我喜欢MongoDB，但我必须说，在我的下一个项目中，我会更加谨慎地使用它。
具体来说，我没有像人们承诺的那样在嵌入式文档功能方面取得太多成功。
嵌入式文档似乎对组合很有用（请参见UML组合），但不适用于聚合。叶节点很棒，但是你的对象图中间的任何内容都不应该是嵌入式文档。这将使搜索和验证数据变得更加困难。
MongoDB中绝对更好的一件事是你的多对X关系。你只需使用两个表就可以实现多对多，并且可以在任一表上表示多对一关系。也就是说，你可以在N行中放置1个键，或者在1行中放置N个键，或者两者兼而有之。值得注意的是，执行集合操作（交集、并集、不相交集等）的查询实际上可以被你的同事理解。我从来没有对SQL中的这些查询感到满意。我经常只能安慰自己“其他两个人会理解这个”。
如果你的数据变得非常大，你就会知道插入和更新可能会受到索引成本的限制。在MongoDB中，你需要更少的索引；A-B-C上的一个索引可以用于查询A、A&B或A&B&C（但不能查询B、C、B&C或A&C）。此外，反转关系的能力使你可以将一些索引移动到辅助表中。我的数据还没有变得足够大，但我希望这样做会有所帮助。