Mongodb文档设计（主要考虑读和更新的频率）
1. 基础篇
考虑因数：一对多中的多是否需要一个单独实体
提出三个类型：内嵌、子引用、父引用
1.1、一对很少
适合内嵌文档
1.2. 一对许多
子级引用
以一产品多零件为例，每个零件都有自己的文档对象（part），
每个产品的文档对象(products)中以数组(catalog_number)存放多零件的objectID
为了快速执行查询，必须确保products.part和part_id存在索引，提高查询速度
缺点：在修改一个零件，需要到所有引用该零件的产品进行更新（需考虑读写频率）
1.3. 一对非常多
一个收集各种机器日志为例 ---->父级引用
由于每个mongodb文档有16M的大小限制，直接存储objectID内存不足
“父级引用” ：用一个文档存储主机，在每个日志文档中保存这个主机的ObjectID
2.提升篇
双向关联、反范式化
2.1 双向关联
任务追踪系统，有person和task两个集合，在各自的集合中都有相关联的对象id
为了快速的获取某个用户负责的项目可以在task对象中嵌入附加的person引用关系
缺点：无法保证操作的原子性，使用该方法，先确认用例是否能允许该操作
2.2 反范式化
你将可能无法对冗余数据进行原子更新
只有读写比较高的情况下才采用反范式化设计
2.2.1 反范式many >> one
以产品（project）和零件（part）为例，在产品（project）中冗余存储零件的名字
产品中保存零件名
考虑问题：考虑产品和零件的修改频率，
零件变化的频率高，付出的更新代价高
零件变化的频率低，付出的更新代价低
2.2.2 反范式 one >> many
冗余产品的名字到零件表
一旦更新产品的名字就必须更新所有和这个产品有关的零件
这个比只更新一个产品对象来说代价明显更大，更要慎重考虑读写频率
总结
1、优先考虑内嵌，除非有什么迫不得已的原因。
2、需要单独访问一个对象，那这个对象就不适合被内嵌到其他对象中。
3、数组不应该无限制增长。
如果many端有数百个文档对象就不要去内嵌他们可以采用引用ObjectID的方案；
如果有数千个文档对象，那么就不要内嵌ObjectID的数组。
该采取哪些方案取决于数组的大小。
4、不要害怕应用层级别的join：如果索引建的正确并且通过投影条件限制返回的结果，
那么应用层级别的join并不会比关系数据库中join开销大多少。
5、在进行反范式设计时请先确认读写比。一个几乎不更改只是读取的字段才适合冗余到其他对象中。
6、在MongoDB中如何对你的数据建模，取决于你的应用程序如何去访问它们。
数据的结构要去适应你的程序的读写场景。
