参考：http://www.cnblogs.com/WeiGe/p/4903850.html
一对多分为关联模式和内嵌模式 内嵌与关联什么时候用： 存在双向查询则用关联，还需用到索引。 当两者是包含关系，并且被包含的对象不会经常的变化，并不会进行双向查询，被包含对象不会进行其他的关联查 则用到内嵌模式 注意，查询频率高的列应该加索引
一对很少 针对个人需要保存多个地址进行建模的场景下使用内嵌文档是很合适，可以在person文档中嵌入addresses数组文档： 
这种设计具有内嵌文档设计中所有的优缺点。最主要的优点就是不需要单独执行一条语句去获取内嵌的内容。最主要的缺点是你无法把这些内嵌文档当做单独的实体去访问。 一对许多 以产品零件订货系统为例。每个商品有数百个可替换的零件，但是不会超过数千个。这个用例很适合使用间接引用---将零件的objectid作为数组存放在商品文档中(在这个例子中的ObjectID我使用更加易读的2字节，现实世界中他们可能是由12个字节组成的)。 每个零件都将有他们自己的文档对象 
每个产品的文档对象中parts数组中将会存放多个零件的ObjectID ： 
一对非常多 我们用一个收集各种机器日志的例子来讨论一对非常多的问题。由于每个mongodb的文档有16M的大小限制，所以即使你是存储ObjectID也是不够的。我们可以使用很经典的处理方法“父级引用”---用一个文档存储主机，在每个日志文档中保存这个主机的ObjectID。
双向关联 如果你想让你的设计更酷，你可以让引用的“one”端和“many”端同时保存对方的引用。 以上一篇文章讨论过的任务跟踪系统为例。有person和task两个集合，one-to-n的关系是从person端到task端。在需要获取person所有的task这个场景下需要在person这个对象中保存有task的id数组，如下面代码所示。 
在某些场景中这个应用需要显示任务的列表（例如显示一个多人协作项目中所有的任务），为了能够快速的获取某个用户负责的项目可以在task对象中嵌入附加的person引用关系。 
这个方案具有所有的一对多方案的优缺点，但是通过添加附加的引用关系。在task文档对象中添加额外的“owner”引用可以很快的找到某个task的所有者，但是如果想将一个task分配给其他person就需要更新引用中的person和task这两个对象