MongoDB的嵌套设计理念

Question

我创建其中一个公司有多个用户的系统，客户等，我不能决定是否进行“对象”，如用户，一个单独的集合或公司文件嵌入文档。

Company (Object) -> 
    Users (Object) -> 
     Profile (Object) -> 
      ...attrs.. 
     History (Object) -> 
      ...attrs... 
    Customers -> 
     ...attrs... 

我困在关系数据库的思维集现在，并不确定“正确”的方式与NoSQL做到这一点。你怎么看？

当双重嵌入式文档（如公司>用户 - >历史记录）得到可笑的大时会发生什么？

对嵌入式文档方法（如果有）有什么其他缺点？再一次，我偏向于关系思维。

在此先感谢。

Answer 1

我可以在这里给出一些一般建议，但最终将由您决定采用哪种方法。你需要询问，以确定是否嵌入或引用的问题是：

你需要什么数据，当您获取大多数查询的文档返回？

这可能很简单或很复杂 - 如果99％的查询要返回相同的5个字段，答案就很明显。如果你很少需要一段数据，那么它是一个单独集合的候选人。您需要进行第二次查找才能获取这些数据，并在它们之间提供某种参考，但稀缺性使得开销可以接受。

当然，如果你的数据集和返回值不那么清晰，那么它就成为一个更复杂的问题。

如果需要频繁使用的字段，但不是所有的需要（比如在历史上最后5项），然后存储它们，固定大小，在主文档中，并在一个单独的集合休息。这会导致一些重复并使您的更新复杂化，但在速度方面可能是一个很好的折衷。

在缺点方面 - 大量嵌入文档不差本身，而是越来越多的一个，特别是一个无界的增长可不好。每次文档增长时，其分配空间可能会太大，这意味着它必须移动。这不仅会在一定程度上分割您的数据，移动大量文档，分配新空间可能是一项昂贵的操作 - 尤其是在您频繁操作时。填充因子文档解释这个相当好（当移动被触发的填充因子增加）：

http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-Overview

希望它能帮助！

Answer 2

如果您不需要查询和自身获得的相关数据统计等，然后使其嵌入这也加快了查询。如果您需要为某种目的提取此数据，请为其创建新的集合。

Answer 3

http://www.mongodb.org/display/DOCS/Schema+Design对架构设计的一些建议，也有各种演示通过像10gen公司的成员这样一条：http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf

考虑到用户的公司可能数量和历史对象的可能数目我想你”我可能会想为每个这些单独收集。