旗帜鲜明地先说结论：之所以新的分布式数据库又开始支持关系模型了，是因为大部分程序员的数据库水平太糟糕。数据库说得复杂特别复杂，但说得简单，它就解决了两个问题：数据怎么存放和数据怎么查询。
一、为什么新的分布式数据库又开始支持关系模型
旗帜鲜明地先说结论：之所以新的分布式数据库又开始支持关系模型了，是因为大部分程序员的数据库水平太糟糕。数据库说得复杂特别复杂，但说得简单，它就解决了两个问题：数据怎么存放和数据怎么查询。
而且这两个问题互相关联。举个程序员都能明白的例子：如果你把数据存成了数组，那搜索查询就只能是O(n)的效率了，如果你存成了二叉树，那么查询效率就变成了O(logn)。
业务查询可不像搜索一个key值这么简单，常常复杂得要死，本来查询就很难写了，现在还得考虑数据物理存放方式来决定怎么执行查询更高效，这不是要逼死人嘛？所以早期的数据库开发人员苦啊，什么层级数据库、网状数据库写完查询都得自己定义access path啊。
然后就有了关系模型。
关系模型彻底改变了数据库程序员的生活：不用管数据怎么存了，你只要用SQL写好查询，然后查询优化器会帮你把面向业务的查询逻辑转换成可以高效在数据的物理结构上执行的物理查询。这简直就像一下从汇编时代跨越到了高级语言的时代啊。早期的数据库还需要大家自己思考怎么建索引，相当于告诉查询优化器哪些列是在查询中有用，后来数据库已经可以自动提示你该加什么索引了，大部分程序员终于可以欢乐地彻底扔掉数据库存储引擎的知识了。
当然仍然有一小挫掌握了超能力的人，是可以手写执行计划，用Plan Guide强制执行的，他们说：查询优化器是什么？可以吃吗？若干年后他们拯救了世界也打开了黑暗的大门(大误…
四
好日子一直持续到数据库负载大到不得不开始走向分布为止。分布式最大的问题是网络延迟问题，而网络延迟是物理问题，没这么容易解决。跨机事务做不了啊，查询优化器再牛逼也优化不了跨网络的join啊。
但业务还是得做啊，于是解决方案只有一个了：回到手工根据查询来决定数据物理分布（这样可以最大程度上避免跨网络的join），手工决定查询的物理执行计划，手工保证事务性的老路。
既然都已经全手工了，那还要原来的RDBMS干嘛，于是NoSQL产品诞生了。搭配一些会手写执行计划手写事务的超能力者使用，战斗力简直有105这么高。
大家很快就忘记了NoSQL其实是一个对现实妥协的产物，只有搭配一些精通数据存储引擎知识的人才能用好。
推广开来之后，广大吃瓜群众表示NoSQL一点也不好用啊，自己要管的东西太多啦，我怎么知道要怎么设计数据的物理分布啊，瞎设计一下查询起来就效率感人了啊，最终一致又是一个什么鬼啦，想象一下讨论怎么严格保证一个“改动了3个entity且有不少if-else分支的方法”的最终一致性，感觉结论必然只有“呵呵”啊。
于是为了让广大吃瓜群众用得开心，NoSQL的开发者不得不又开始走上了关系模型的老路。
延伸阅读：
二、Access的优点
（1）存储方式简单，易于维护管理，Access的对象有表、查询、窗体、报表、页、宏和模块，以上对象都存放在后缀为（.mdb或.accdb）的数据库文件中，便于用户的操作和管理。
(2)面向对象 Access是一个面向对象的开发工具，这种基于面向对象的开发方式，使得开发应用程序更为简便。
（3）界面友好、易操作，Access是一个可视化工具，是风格与Windows完全一样，用户想要生成对象并应用，只要使用鼠标进行拖放即可，非常直观方便。系统还提供了表生成器、查询生成器、报表设计器以及数据库向导、表向导、查询向导、窗体向导、报表向导等工具，使得操作简便，容易使用和掌握。
（4）集成环境、处理多种数据信息，Access基于Windows操作系统下的集成开发环境，该环境集成了各种向导和生成器工具，极大地提高了开发人员的工作效率，使得建立数据库、创建表、设计用户界面、设计数据查询、报表打印等可以方便有序地进行。
（5）Access支持ODBC（开发数据库互连，Open Data Base Connectivity），利用Access强大的DDE（动态数据交换）和OLE（对象的联接和嵌入）特性，可以在一个数据表中嵌入位图、声音、Excel表格、Word文档，还可以建立动态的数据库报表和窗体等。Access还可以将程序应用于网络，并与网络上的动态数据相联接。利用数据库访问页对象生成HTML文件，轻松构建Internet/Intranet的应用。
