数据线索梳理

数据这块水太深，我从头梳理一下。

60 年代开始大家开始考虑数据处理的模型，因为磁带出现，大容量数据处理成为可能。

按人类大脑中对数据、概念的理解，模型也就只能搞出几种：网络型，继承型，记录/Record 型，对象 Object 型，关联/Aasscotive 型。

到 70 年代，Record 一统天下，但其主流的的名字却叫关系/Relational，速成 RDB。

这 2 个 R 就体现了其最主要的特征：存储靠 record，计算靠 relation。

为什么 rdb 会胜出？斗胆猜测

首先是 record 最直白将概念表达出来，信息化初期 这部分需求占了多数，而且也是信息化的第一步，用最简单的方式受众最多。

大部分公司都在信息化初期，这步做好后，后续演化才能顺利。

rdb 也有其自身的结构性问题，就是逻辑表达复杂，逻辑和数据 layout 强耦合，逻辑复用成本高。可以说是入门容易，修行难。

这个影响一直延续到现在，比如我们碰到的问题，struct 就是 record，符合类型中需要 key 关联到其它类型，为此模型写逻辑代码，难度高，一不留心就掉坑里。

80 年代开始 OO 做为该问题的一种解决方案王者归来，差点团灭了 RDB。最后 2 者融为一体，成了关系对象混合 DB。

虽然说的是 DB，但其背后的问题，编程范式，数据处理模型，都可映射到软件的其它领域。

开头说的 5 大模型，其它 3 个一直游离在主流商业之外，所以受到的关注少。

网络模型在深度学习中大放异彩，关联模型也是基因工程中唯一可用的模型，互联网超大规模数据 KV 也是关联模型的一种。

只有继承模型，可能就像数学大厦的歌德尔定理，复杂到一定程度的系统终将崩塌。

最后这句最关键，因为我们目前软件构建的系统，本质都是简单系统。所以不要尝试构建复杂系统，就连最简单的复杂关系-继承也要少用。

小结一下，

Record 虽然不是唯一选择，但是最简单的现在，本着对复杂敬畏的态度，我们选择 ta；

relation 不是最简单的，但却是最容易的，把锅甩给了程序员；

程序员自救，一直推动 OO，之前的推动者可不是程序员；

到现在，程序员何必为难程序员，OO 从我做起，不给他人惹麻烦。