MongoDB 存储引擎和数据模型设计(2)

这里同样也引伸出一个“冗余”的问题，我们知道大多时候我们需要查询的数据属性数目是比较少的，比如对于学生而言，我们可能只需要知道他的身高体重，所以我们可以使用“冗余”思想简单修改刚才的集合成以下格式来应付

> db.school.findOne() { _id:ObjectId("cccc"), name:"middle1", location:"wenzhou", students:[ {ObjectId("xxxx"),name:"wddpct",height:233,weight:233}, {ObjectId("yyyy"),name:"wddmd",height:233,weight:233} …… ] }

不过也要注意的一点是，这样每次更新student的信息时，不免又要对school中的冗余信息进行更新，所以也要结合具体场景使用

**

C. 1 - *（非常多）

**

地区和车牌的关系勉强属于此类，一个地区可能有几十上百万车牌，我们不可能再像刚才那样在area中加入所有的license_id，不然可能光是单个文档大小就超过MongoDB的16MB限制了，而且对于查询也存在很大的负担。

这里我们可以直接套用关系型数据库中的外键思想，在license集合的末尾加入area_id就可以方便解决此类关系

> db.license.findOne() { _id:ObjectId("cccc"), license:"middle1", area:ObjectId("xxxx") }

当然，我们也可以对area进行进一步冗余，所以就不额外说明了。

**

D. * - *

**

对于多对多关系模型，可能又要祭出那句老话——“视具体情况而定”。不过一般情况下，它不过就是一对多关系的几个变种。一个基本的原则是考虑两边统一引用对方的ObjectId，适当冗余部分信息。

除此以外，我们还可以从以下几个原则去考虑

两边的数量比（较大方更适合引用）

两边的更新频率比（较大方更适合引用）

两边的读取频率比（较大方更适合内嵌）
……

E. 通用建议

以下给出一张较通用的建议表，仅供参考

内嵌引用
子文档较小   子文档较大  
数据不会定期更改   数据经常改变  
最终数据一致即可   中间阶段数据也必须一致  
文档数据小额增加   文档数据大幅增加  
数据通常需要执行二次查询   数据通常不包含在查询结果中  
快速读取   快速写入  

更多MongoDB相关教程见以下内容：

CentOS 编译安装 MongoDB与mongoDB的php扩展

CentOS 6 使用 yum 安装MongoDB及服务器端配置

Ubuntu 13.04下安装MongoDB2.4.3

MongoDB入门必读(概念与实战并重)

Ubunu 14.04下MongoDB的安装指南

《MongoDB 权威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

Nagios监控MongoDB分片集群服务实战

基于CentOS 6.5操作系统搭建MongoDB服务 uxidc.com/Linux/2014-11/108900.htm

MongoDB 的详细介绍：请点这里
MongoDB 的下载地址：请点这里