网状模型
network model是hierarchical model 的一种扩展：允许一个节点有多个父节点。它被数据系统语言会议的委员会进行了标准化，因此也被称为CODASYL模型。
多对一和多对多都可以由路径来表示。访问记录的唯一方式是顺着元素和链接组成的链路进行访问，这个链路叫访问路径。难度犹如在n-维空间中进行导航。
内存有限，因此需要严格控制遍历路径，并且需要事先知道数据库的拓扑结构，这就意味着得针对不同应用写大量的专用代码。
关系模型
在关系模型中，数据被组织成元组（tuples），进而集合成关系（relations）；在SQL中分别对应行（rows）和表（tables）。
表只是一种实现，关系的说法来自集合论，指的是几个集合的笛卡尔积的子集。 R ⊆ （D1×D2×D3 ··· ×Dn） （关系用符号 R 表示，属性用符号 Ai 表示，属性的定义域用符号 Di 表示）
其主要目的和贡献在于提供了一种声明式的描述数据和构建查询的方法。即，相比网络模型，关系模型的查询语句和执行路径相解耦，查询优化器（Query Optimizer 自动决定执行顺序、要使用的索引），即将逻辑和实现解耦。
举个例子：如果想使用你的方式对你的数据集进行查询，你只需要在新的字段上建立一个索引。那么在查询时，你并不需要改变你的用户代码，查询优化器便会动态的选择可用索引。
文档型 vs 关系型
根据数据类型来选择数据模型
| 文档型 | 关系型 | |
|---|---|---|
| 对应关系 | 数据有天然的一对多、树形嵌套关系，如简历。 | 通过外键 + Join 可以处理 多对一，多对多关系 |
| 代码简化 | 数据具有文档结构，则文档模型天然合适，用关系模型会使得建模繁琐、访问复杂。但不宜嵌套太深，因为只能手动指定访问路径，或者范围遍历 | 主键，索引，条件过滤 |
| Join 支持 | 对 Join 支持的不太好 | 支持的还可以，但 Join 的实现会有很多难点 |
| 模式灵活性 | 弱 schema，支持动态增加字段 | 强 schema，修改 schema 代价很大 |
| 访问局部性 | 1. 一次性访问整个文档，较优 2. 只访问文档一部分，较差 |
分散在多个表中 |
对于高度关联的数据集，使用文档型表达比较奇怪，使用关系型可以接受，使用图模型最自然。
文档模型中Schema的灵活性
说文档型数据库是schemaless不太准确，更贴切的应该是schema-on-read
| 数据模型 | 编程语言 | 性能 & 空间 | ||
|---|---|---|---|---|
| schema-on-read | 写入时不校验，而在读取时进行动态解析。 | 弱类型 | 动态，在运行时解析 | 读取时动态解析，性能较差。写入时无法确定类型，无法对齐，空间利用率较差。 |
| schema-on-write | 写入时校验，数据对齐到 schema | 强类型 | 静态，编译时确定 | 性能和空间使用都较优。 |
文档型数据库使用场景特点：
- 有多种类型的数据，但每个放一张表又不合适。
- 数据类型和结构由外部决定，你没办法控制数据的变化。
