多对一和多对多
是一个对比各种数据模型的切入角度。
region在存储时，为什么不直接存储纯字符串：“Greater Seattle Area”，而是先存为region_id -> region name，其他地方都引用region_id？
统一样式：所有用到相同概念的地方都有相同的拼写和样式
避免歧义：可能有同名地区
易于修改：如果一个地区改名了，我们就不用去注意修改所有引用他的地方
本地化支持：如果翻译成其他语言，可以只翻译名字表
更好搜索：列表可以关联地区，进行树形组织
类似的概念还有：面向抽象编程，而非面向细节。
关于用ID还是用文本，作者提到了一点：ID对人类是无意义的，无意义的意味着不会随着现实世界的将来的改变而改动。
这在关系数据库表设计时需要考虑，即如何控制冗余，会有几种范式来消除冗余。
文档型数据库很擅长处理一对多的树形关系，却不擅长处理多对多的图形关系。如果其不支持Join，则处理多对多关系的复杂度就从数据库侧移动到了应用侧。
如，多个用户可能在一个组织工作过，如果我们想找出同一个学校和组织工作过的人，如果数据库不支持Join，则需要在应用侧进行循环遍历来Join。
文档 vs 关系
对于一对多关系，文档型数据库将嵌套数据放在父节点中，而非单拎出来放另外一张表
对于多对一和多对多关系，本质上，两者都是使用外键（文档引用）进行索引。查询时需要进行join或者动态跟随。
文档模型是否在重复历史？
层次模型
20世纪70年代，IBM的信息管理系统IMS。
几个要点：
树形组织，每个子节点只允许有一个父节点
节点存储数据，节点有类型
节点之间类似指针方式连接
可以看出，它与文档模型很像，也因此很难解决多对多的关系，并且不支持Join。
为了解决层次模型的局限性，人们提出了各种解决方案，最突出的是：
关系模型和网状模型
