MongoDB中数据的非规范化
我正在学习MongoDB，我有一个关于数据重复的问题。 在SQL世界中，您尝试规范化数据。 例如，我有一个表与类别和另一个与产品。 每个产品可能属于多个类别，因此这些表格之间有一个连接。
但是我在MongoDB中是不是这样想？ 相反，每个产品都有一个embedded式文档（一个或多个）？ 这就是这样吗？ 你不在乎数据是否重复？
在SQL世界中，您尝试规范化数据
并不总是，规范化到死亡点造成了性能问题，但是我个人并没有像SQL那样对MongoDB应用相同的规范化。
如果您知道规范化的表单（ http://en.wikipedia.org/wiki/Database_normalization ），我喜欢将MongoDB视为转到1NF，然后再返回到非规范化。
你不在乎数据是否重复？
哦，是的，我们做。 如果数据重复错误，更新是一件痛苦的事情。
让我举个例子： category和product将是两个独立的实体，不能否认。 这两个实体是正常化的（产品的重复数据已经从category ）。 另一种思考的方式是： 所有产品是否只存在于一个类别中？
因此，在顶层实体中，您可以看到，与1NF轻松应用于MongoDB相同的规则相对适用。
在重复的前面，当然，你不希望在每个类别中分别存储每个产品（我对上述问题的回答是否定的），所以你自然要分离产品和产品。
在这里，你通常会有一个多对多的关系，并且有一个中等规格的表格。 这就是去规范化的地方。你可以说一个类别将有一个该类别唯一的产品列表，这样你可以将多对多的关系表作为一个列表去规范化到类别行（或者反过来进入产品行）。 这不会产生重复，因为该列表对于该类别是唯一的（很可能）。 这当然意味着一个或多个产品将包含相关行的列表_id而不是对象本身。
有时候，重复是必要的，主要是为了优化或者为了没有JOIN而变通; 这个规则也适用于SQL，如果你曾经做过足够大的网站。
典型的重复使用场景是统计信息的聚合字段，比如Facebook发布股票和评论，甚至可以将该post的5个最新评论复制到post行中。
所以这不是忽略模式devise的情况，而是更多地针对MongoDB特性进行调整。 通常情况下，如果你这样做，你会发现你自然会devise一个好的模式。
作为一个附加的参考，你可以参考这里： http : //docs.mongodb.org/manual/core/data-modeling