之前，我真的下潜深入到MongoDB的几天，我想我会问一个非常基本的问题，就是我是否应该潜入它在所有与否。我基本没有使用nosql的经验。MongoDB的正常化，外键和加入
我看过一些关于一些文档数据库的利益，我觉得这个新的应用程序，他们会真的很棒。对许多类型的对象（大量m-to-m关系）和子类进行收藏夹，评论等操作总是一件麻烦事 - 处理起来会很痛苦。
我也有，这将是一个痛苦的SQL来定义，因为它是非常嵌套，并转换为文档的很多比15代不同的表更好的结构。
但我对一些事情感到困惑。
是否需要保持数据库正常化？我真的不想更新多个记录。那仍然是人们如何处理MongoDB中数据库的设计？
当用户收藏夹一本书，这个选择是仍然存储在用户的文件，但后来这本书被删除，会发生什么？如何在没有外键的情况下解除关系？我是否负责手动删除所有链接？
如果用户收藏最多的一本书不再存在，会发生什么，我查询它（某种加入的）？我必须在这里做任何容错吗？
MongoDB不支持服务器端外键关系，标准化也不鼓励。如果可能的话，你应该将你的子对象嵌入到父对象中，这样可以提高性能，并且完全不需要外键。这就是说它并不总是可能的，所以有一个称为DBRef的特殊构造，它允许引用不同集合中的对象。这可能不那么快，因为数据库必须进行额外的查询来读取对象，但允许一些外键引用。
您仍然需要手动处理您的参考。只有在查找DBRef的时候，你会看到它是否存在，如果引用的目标不再存在，数据库将不会遍历所有的文档来查找引用并删除它们。但是我认为在删除书后删除所有参考文献将需要每个集合一个查询，不再需要，所以不是那么难。
如果你的模式是比较复杂的则可能是你应该选择一个关系型数据库，而不是NoSQL的。
还有一本关于设计的MongoDB数据库：Document Design for MongoDB
UPDATE上面的书已不存在，MongoDB中的普及又因为有相当多的人的。我不会将它们全部链接起来，因为这些链接可能会发生变化，亚马逊上的简单搜索会显示多个页面，因此找到一些内容不应该是个问题。
进一步的细节和例子
在上面看到了'Manual references' and DBRefs MongoDB的手册页，@TomaaszStanczak指出
的MongoDB不支持服务器端外键关系， 正常化也望而却步。如果可能的话，您应该在父对象中嵌入您的子对象 ，这会提高性能，并且完全不需要外键。这就是说它并不总是 可能...
规范化不是灰心蒙古。清楚的是，我们正在谈论两个数据实体可以具有的两种根本不同类型的关系。其中一个子实体仅由父对象拥有。在这种类型的关系中，Mongo方式将被嵌入。
在另一类关系中，两个实体独立存在 - 具有独立的生命期和关系。 Mongo希望这种类型的关系不存在，并且对于如何处理这种关系感到沮丧而沉默。嵌入不是一个解决方案。规范化不是不鼓励或鼓励的。 Mongo只是给你两个机制来处理它; Manual refs（类似于具有绑定两个表的外键约束的键）和DBRef（这是一种不同的，稍微更加结构化的方式）。在这个用例中，SQL数据库赢了。
+1同意。在互联网上的引用就像“一般来说，在MongoDB中，您希望以应用程序访问它的方式存储数据，从而消除了对连接的需求”是常见的，但您的独占所有权和推断的稳定性数据往往被忽视。 – 2015-11-26 20:52:27
当您执行SQL数据库（如MySQL）时，即使通过外键连接，它们也不会自动删除表之间的链接。他们所做的唯一的事情就是阻止你删除另一个由外键连接的表中的行，但即使在那里，它也只有在你告诉它时才会这样。你为什么会认为NoSQL会有所不同？ – trysis 2014-07-23 13:14:52
@trysis，google ON DELETE CASCADE。 – 2015-01-16 08:36:10
是的，我忘记了为什么我说那是很久以前的事了。如果我误导了过去无知的人，我很抱歉。 – trysis 2015-01-17 00:07:16