说“当时建立的数据库使用层次模型”并不完全正确。
首先（挑剔），数据库管理系统使用/不使用某些物理结构。 “数据库”——即数据库设计可能会使用各种抽象。无论最终的物理平台如何，实体关系建模作为一种设计工具曾经并且仍然很流行。
其次，当时虽然分层模型通常用于“大铁”大型数据库，索引顺序 https://en.m.wikipedia.org/wiki/ISAM在过去所谓的“迷你计算机”上更为常见（例如 DEC PDP-8/-11；IBM System/34,/36；ICL 1900/ME29；Honeywell DPS4/DPS7）。
我们可以说磁盘上的索引顺序组织是从使用批量复制更新的打孔卡或磁带系统发展而来的。这就是“顺序”的由来。
你说你不想问具体的实施情况；但答案都是关于实际执行。顺序读取磁盘比随机访问（需要读头跳跃）更有效。这就是为什么与磁盘相反，内存被称为“随机存取存储器”。 （这是在 RAM 变得如此便宜以至于我们可以在内存中保存整个数据库之前很久的事了。）
同样，分层模型的组织是为了提供对常用查询路径的快速访问。该层次结构将紧密链接的节点放在物理磁盘的同一块上。因此，可以轻松地从客户导航到该客户的订单，再到该订单的项目行。
缺点是很难“跨”层次结构进行导航，例如查找项目 P5432 的所有订单行，无论是哪个客户/订单。 （此外，如果您想检索订购 P5432 的客户，您需要在层次结构中“向后”工作。如果它们都在同一块磁盘上，希望您不需要看得太远/也许它在加载到 RAM 的同一磁盘桶。）
类似地，索引顺序组织偏爱一种特定的索引——主键。如果您想按客户名称而不是号码进行搜索，则需要一个具有各种丑陋组织的“二级索引”，以将索引存储桶保留在数据附近的某个位置。还有臭名昭著的“桶溢出”，当您修改名称中的一个微小的拼写错误并将其转移到完全不同的字母位置时，它可能会导致机器停止运行。
（顺便说一句，NoSQL 数据库作为只有一个键的键值存储，似乎注定会陷入与二级索引有关的所有这些陷阱。它们需要第二个键值存储来提供替代索引，其中包含各种索引让它们保持同步很有趣。回到未来！）
Codd 在实现关系模型时遇到的最大问题是说服 IBM 高层相信该模型可以有效地支持通过多个“访问路径”进行查询。您会看到他的许多早期论文都在谈论将“导航”从查询编写器/程序员中抽象出来。事实上，最初的 System/R 设计有很多妥协，因为
a) IBM 工程师只是不理解 Codd 所说的数学抽象；
b) 他们非常害怕它会像狗一样表现，他们会失去工作。
[咳咳！个人观点：但是这个小组很久之后才聚在一起，并且在网络上有一些回忆。] 这些妥协一直持续到今天在 SQL 中；坦率地说，这是一堆垃圾，应该仅仅作为一个有趣的概念证明而被删除。
Codd 的模型是如何成功的（或者更确切地说 SQL 模型，not科德）？
比赛开始了！没有时间停下来把一切都做好。实施您所拥有的内容（即 SQL 概念证明）并尽快将其推向市场，无论是否准备就绪。 （听起来是不是很熟悉的故事？）
您关于关系模型优越性的观点都很充分。它们本质上遵循标准化技术。不过，我想说的是，在 70 年代末/80 年代，人们并没有很好地理解它们。模式设计看起来很像分层或索引顺序数据模型，只是转换为“平面”表。特别是，有一种趋势是设计“宽”表，将我们所知道的有关某个客户的所有信息集中在一块磁盘上，而不是垂直分区。 （因为担心将分区连接在一起会影响性能。）这意味着很多不适用或“未知”的字段——这是 SQL 的 null 令人厌恶的地方。
所以你的“改进”还只是部分实现。也许有一天我们会看到一种针对关系模型设计的 DBMS。现在我们必须忍受 SQL。
