Relational Model Versus Document Model
The Birth of NoSQL
主要是讲了一下rdms的历史和发展 然后又讲了一下nosql……
The Object-Relational Mismatch
需要一层额外的映射，从relational到object，也就是orm
这里举了一个个人简历的例子，里面的教育经历，工作经历是一个数组，对于这个场景document模型比relational模型会避免missmatch的情况，在本章稍后也会讲document的schema flexibility被看作是一种优势。
Many-to-One and Many-to-Many Relationships
relation模型会使用维表来避免重复的数据（normalization），document模型要做这件事情的话，没有来自底层的join机制，只能自己在应用层做。
Are Document Databases Repeating History?
denormalize or references, 1970s IBM的ims就有这个问题，ims是一种分层的model，类似json，而最终基于分层模型扩展的relational model发展下来network model变得很罕见。
The network model
hierarchical是一棵树，network是一个图，类似维表这种数据在图中会有多条输入边，这样避免了join，实现了many-to-one和many-to-many。感觉很难用。
The relational model
自动化的query optimizer 远强于network model的access path。
general-purpose optmizer在长时间的运行里是要比handcode的更优。
Relational Versus Document Databases Today
概括地说，各自的优点
relational
join
many-to-one, many-to-many relationship
document
schema flexibility
better performance due to locality
closer to data structures
Which data model leads to simpler application code?
主要关注的指标还是是否要做analytics，join对于document比较尴尬。
作者的观点是，应用程序里面多次请求，效率是低于直接在db里join的，和国内的实践不一致，国内很多大公司mysql都不允许使用join，或者>n表的join了，反而在应用程序里面做。如果不在db里面做join那为什么用mysql，不直接用nosql？不过要考虑分库的问题。
Schema flexibility in the document model
schemaless -> misleading -> accurate terms is schema-on-read，而对于traditional db是schema-on-write
这两个概念和dynamic type checking/static type checking相近
更多的还是看模型结构是否确定
Data locality for queries
document模型，如果要一次把整个document拉出来渲染，性能会非常好，对应的场景下，relational模型要按索引去多次寻址，性能会比较差。但是这个说法其实是在relational遵循范式而document不遵循的情况下讲的，放在一样的基准下应该沿用前面join上的说法。
如果只读document中的一小部分，性能浪费比较严重。
如果update使document的size变大，性能会比较差。
Convergence of document and relational databases
按照这一章目前位置讲的内容，mysql在relational db里面，似乎是比较差的，很多特性都不支持。
其实很奇怪的一点是document模型为何对维表join支持的不好。
Query Languages for Data
声明式语言比命令式语言在并行化上更加的简单
存疑，声明式隐藏了细节，最终执行的时候还是要依赖命令式，如果底层不支持呢？
Declarative Queries on the Web
MapReduce Querying
higher-level query languages like SQL can be implemented as a pipeline of MapReduce operations
Graph-Like Data Models
homogeneous data 同质化
非同质化的应用，边和顶点的类型不限定
Property Graphs
vertex
id
incoming edges
outgoing edges
kv
edge
id
tail vertex set
head vertex set
relationship
kv
用这个结构可以描述非同质化图
一些特性
no schema
efficiently scan
store several different kinds of information in a single graph
The Cypher Query Language
declarative query language for property graphs
Graph Queries in SQL
主要是join的问题，在一个图里需要遍历之后才直到要如何join
SQL:1999 - recursive common table expressions
但是实际写起来比Cypher Query笨重太多
Triple-Stores and SPARQL
equivalent to the property graph model
(subject, predicate, object) -> (Jim, likes, banbanas)
(lucy, age, 33) - predicate is a property - object is a string literal
(lucy, marriedTo, alain) - predicate represents an edge - object is a vertex
The semantic web
Resource Description Framework = RDF
和tripler-store没啥关系……
The RDF data model
emmm…
you can just specify this prefix once at the top of the file, and then forget about it.
The SPARQL query language
The Foundation: Datalog
similar to the triple-store
predicate(subject, object)
事实上查询的方式和sparql区别还是挺大的，要先定义rule，类似function，然后利用rule的派生(derived)来做类似:within*的语义
Summary
这一章讲的都比较简单，感觉不是很有干货，也有可能是我水平不够，嗯……
若有收获，就点个赞吧
0 人点赞
