关系模型战胜网络模型的关键是查询优化器只需构建一次

20世纪70年代，如何处理多对多关系有过一场”大辩论”，最终关系模型胜出，其历史逻辑 在今天理解文档数据库的局限依然有参考价值。最早的层次模型（IMS）把所有数据表示成 嵌套记录树，天然擅长一对多关系，却难以应对多对多关系——这和今天文档数据库遇到的 问题几乎一样。网络模型（CODASYL）是层次模型的推广：一条记录可以有多个父节点， 从而能表达多对多关系；但记录之间的链接不是外键，而更像程序里的指针，访问记录唯一 的方式是沿着预先设定的”访问路径”从根记录出发遍历——如果一条记录有多个父节点、多条 不同路径都能到达它，程序员就必须自己在代码里跟踪这些路径，连CODASYL委员会成员都 承认这就像在n维数据空间中导航。这种”手动选择访问路径”的方式在硬件资源极其有限 （比如磁带驱动器）的年代确实高效，但代价是查询和更新代码变得复杂脆弱，一旦想按 新方式查询数据，往往需要大量重写手写的访问路径代码。关系模型的做法完全不同：把 所有数据摊开放在光天化日之下——一个关系就是一堆元组的集合，没有嵌套结构，没有 预先固定的访问路径，你可以按任意条件选取行，插入新行也不需要操心与其他表的外键 关系。真正的关键差异不是”有没有连接”，而是”谁来决定访问路径”：在关系模型里，查询 优化器自动决定使用哪些索引、按什么顺序执行查询的各部分，这个决策过程只需要构建 一次，此后所有使用该数据库的应用都能从这一次投入中持续受益；而网络模型把这个决策 责任丢给了每一个程序员，每次新查询需求都要重新手写。

结构图：

flowchart LR
    A[层次模型: 记录树, 擅长一对多] -->|多对多支持差| B[网络模型 CODASYL]
    B --> B1[记录可有多父节点, 支持多对多]
    B1 -.访问靠预设访问路径, 程序员手动跟踪.-> B2[查询代码复杂脆弱, 改查询需重写路径代码]
    A -->|同样多对多支持差| C[关系模型]
    C --> C1[数据摊平为元组集合, 无预设访问路径]
    C1 --> C2[查询优化器自动决定索引与执行顺序]
    C2 -.只需构建一次, 所有应用持续受益.-> C2