在我深入研究MongoDB几天之前，我想我应该问一个非常基本的问题，我是否应该深入研究它.我基本上没有使用nosql的经验.
我确实读了一些关于文档数据库的好处的书，我认为对于这个新的应用程序来说，它们将非常棒.对很多类型的对象(很多m-to-m关系)和子类进行Collection 夹、 comments 等操作总是很麻烦，这是一种很难处理的问题.
我还有一个在SQL中定义的 struct ，这将是一个痛苦的过程，因为它是非常嵌套的，并且比15个不同的表更好地转换为一个文档.
但是有几件事我很困惑.
保持数据库正常化是可取的吗？我真的不想更新多个记录.这仍然是人们在MongoDB中设计数据库的方式吗？
如果用户Collection 了一本书，并且此 Select 仍存储在用户文档中，但随后删除了该书，会发生什么情况？如果没有外键，关系是如何分离的呢？我是否自己手动负责删除所有链接？
如果用户喜欢一本不再存在的书，而我查询它(某种形式的加入)，会发生什么？我必须在这里进行容错吗？
MongoDB不支持服务器端外键关系，也不鼓励规范化.如果可能，您应该将子对象嵌入父对象中，这将提高性能并使外键变得完全不必要.也就是说，这并不总是可能的，所以有一个名为DBRef的特殊 struct ，它允许引用不同集合中的对象.这可能不会那么快，因为DB必须进行额外的查询才能读取对象，但允许某种外键引用.
不过，您仍必须手动处理您的推荐人.只有在查找DBRef时，您才会看到它是否存在，如果引用的目标不再存在，DB将不会遍历所有文档来查找引用并删除它们.但是我认为在删除书之后删除所有引用只需要每个集合一个查询，不需要更多，所以并不是很困难.
如果您的模式更复杂，那么您可能应该 Select 关系数据库，而不是nosql.
还有一本关于设计MongoDB数据库的书:Document Design for MongoDB
UPDATE以上这本书已经不再有了，但由于MongoDB的流行，还有相当多的其他书.我不会全部链接，因为这样的链接可能会改变，在亚马逊上简单的搜索就会显示多个页面，所以找到一些应该不是问题.
有关更多细节和示例，请参阅MongoDB 'Manual references' and DBRefs手册页