数据模型以及查询语言

The limits of my language mean the limits of my world!
这是《Design Data-Intensive Applications》第二章的序言。

请教了几个身边英语比我好的朋友，最终有个朋友，通晓日语和英语，还有 SQL 的硕士，翻译的比较时下：

别让语言，限制了我们的想象力！

数据模型以及查询语言

1. 当我们是一个应用开发人员，我们关系的是真实世界的模型。比如任务，组织，活动，现金流，传感器传输等。对象及其数据结构都是专属于这一个软件系统的。
2. 当我们设计好了软件系统，需要存储其中用的数据时，我们使用的标准会是，Json, XML, 关系型二维表等。
3. 我们不会去构建怎么设计 Json, XML, 二维表等在内存，磁盘，网络中的存储和传输，这些都是由更底层的开发人员来设计。
4. 内存，磁盘，网络的物理存在，又是由硬件设计制造人员来开发，他们的工作包括了设计电路，光信号等。

可见，在每一个独立的领域背后，都有自己善用的数据模型，以及匹配的查询语言！

SQL 的起源：

在20世纪60到70年代，由于大量的业务数据需要处理，比如大型机开始处理事务性数据，股票购买，机票预订，销售订单等，也开始处理批次数据，工资支出，报表打印等。基于此类需要， Edgar Codd 在1970年，开始提出 SQL 模型，并与 20世纪80年代中期，得到最广泛的使用。

在此之后，出现了 network model, hierarchical model，XML 等模型，但都没有能撼动 SQL 模型在业界的地位。至今统领了数据江湖近 30 多年。直到下一个挑战者 NoSQL的出现。

NoSQL的出现：

NoSQL 的出现有其必要性：
1. 快速分布式的查询。传统的关系型数据库比较重型，分布式扩展不是特性敏捷，而 NoSQL 的出现，弥补了这部分需求。分布式查询既可以提高容量，还可以提供集群高性能的计算。
2. NoSQL 是完全开源的，比起传统的商业数据库，性价比更高
3. 有些特殊的查询操作，比关系模型支持的更好，比如全文搜索， ElasticSearch 就比关系模型强。
4. NoSQL 对 schema 的约束更少，支持更多的数据模型，以及更动态的数据模型表达

在 Rational Data Model 下 OOP 编程的尴尬：

OOP(Object Oriented Programming)面向对象的编程方法，已经大行其道了。凡事都先建类，已经是OOP俗成的约定了，类的数据结构必定是key-value形式存在的，与二维表并不能很好的套用。比如一张二维表只能看作是一个实体，而与其有关系的其他实体的属性，由于范式的约束，是不能存在同一张表里面的 ，而类却是可以的，一个类可以同时保存其他类的属性，状态值等等。所以在切换类到二维表实体的时候，需要一层转换，通常为了编程的方便，我们简化了这层抽象，称之为ORM(Object - Retional Mapping), 比如 Java 的Hibernate . 但无论如何，始终避免不了手工实现一些特殊的转换。

我们举一个例子看看：

负责存储一个人的信息，必定需要同时存储好几张表，比如个人的姓名，住址，籍贯，教育信息，工作单位，还有社交网络账户等等。这些信息可以是单一形式的存在，即在某些领域，一个人只能有一个专属于自己的信息，比如中华人民共和国公民身份证； 而在某些领域，个人信息是以复数形式存在，比如一个人可以有很多属于自己的社交账户，手机账户等等。

当我们需要汇总一个人信息的时候，需要查询这些所有个人信息有关联的表，因此有可能会受到表结构的影响，数据量的影响，造成访问缓慢等一系列问题。

而如果我们用Json 格式来保存个人信息的话，就方便多了。将所有的个人信息都放在一个文档里面，一旦定位到这个人，就抽取他的文档，所有的个人信息不必再通过查询多个表来找到了。我们看看Json文档是如何存储个人信息的数据：

而且支持Json文档格式的NoSQL 数据库(比如 MongoDB, RethinkDB, CouchDB, Espresso) 厉害的一点是，可以被索引。基于任何一个key都能做索引，比如要对个人的社交账户做索引，只要在contact_info.Twitter上加一个索引即可，这在传统的RDBMS里面是做不到的。

而这个时候，类到Json 的转换，就无缝接入了。当然也不是完美的方案，总会有写需要人工介入的地方，有关于这些问题，以后再深入。

---

欢迎关注【有关SQL】，入群讨论技术