简单聊聊数据模型

一个data system最重要的部分就是数据模型，正如某人所言，程序=数据结构+算法，那么数据模型就是程序中的数据结构了。数据模型不仅仅影响着数据的存储，而且决定了我们解决问题的方式。 很多应用都建立在数据库之上，比如下图，便是不同layer对数据的使用，我们可以看出一个良好的数据模型在中间起着至关重要的作用。数据模型有很多种，但是没有万能的解决方案，只有更适合解决问题的模型。总的来说，最常用的有the relational model、the document model以及一些graph-like model。

当然在这三者中，最出名的模型莫过于基于relational model的SQL，其核心思想在1970年便已提出，data is organized into relation(tables), where each relation is an unordered collection of tuples(rows)。relational model主要是服务于business data processing，后来称其为transaction processing。不过当时还有一些其他模型与relational model竞争，比如the network model和the hierarchical model。进入二十一世纪，随着业务的复杂，NoSQL诞生了，Nosql比relational model更适合于高吞吐和大数据的场景，再加上开源和一些不适合SQL查询场景的出现，NoSQL火了起来。 relational model与现在流行的面向对象的编程语言有着天然的鸿沟，也就是所谓的impedance mismatch。ORM框架的诞生便是为了弥补这个，但是也并不能完全做到一致。例如有一个网站，有这么一类数据，就是简历的数据，如下图

1.我们可以基于relational model的解决方案就是切分简历信息，建立一个叫做user table的主表以及包含着相关信息，例如position table，education table之类的副表，通过unique id和foreign keyjoin在一起。 2.依然使用relational model，但是只使用一张表，education table之类的信息通过JSON和XML的方式存储在a single rows。 3.完全变成JSON的格式，比如{name:xxx,education:[{school name:xxx},{school name:xxxx}]} 作为一名程序员，JSON弥补了impedance mismatch，你可以把它当作字典和列表去处理。而且JSON比方案1的多表更容易存储在本地，使得程序的反应速度大大加快。例如简历的这种是典型的one-to-many relationships，如下图。你也可以理解为树形结构。 简历信息当中也许会存在居住地信息，这些信息都是以文本的信息存储，但是我们更应该把他们变成一个个对应的id，这样使得数据不会再如文本数据一样具有歧义，更容易更新。而这就是所谓的normalization。但是这个更适用于many-to-one relationships,与JSON这样的表达形式不怎么搭配。这时候，你也应该可以想到the document model对于join的支持是不太友好的。 再回到the relational model，这个就是rows的集合。从定义上来看，我们也会发现，这个不再具有the document model那样的耦合了，获取数据也不再需要遍历文本了。而且核心不在于开发者写的程序，而是the query optimizer。对于many-to-one和many-to-many relationships，document model和relational model两者没有本质上的区别，仅有的差别也在于join和follow-up query花费的时间。 如今两者已经没有非常明显的差别了。JSON这种的document，一般来言会称为非结构化数据，但是更精确的表达应该是schema-on-read，如编程里的动态语言，relational model则是schema-on-write，就是需要经过编译的静态语言。