野猪书读书笔记(第二章)
数据模型和查询语句
数据模型不仅会影响我们如何编写代码，更重要的是，它会指导我们如何思考正在处理的问题。
绝大部分应用的构建都可以抽象成一层数据模型叠加在另一层之上，因此，如何表现每一层的数据成为了关键点。
层级数据模型的基本点在于：每一层都应该隐藏自己的复杂度并向外提供干净的数据模型。
关系型 vs 文档型
不同类型的应用可能需要不同类型的数据模型，在可预见的未来，应该是 关系型数据 的大量使用伴随着其他 非关系型数据 的应用，也就是所谓的 混合型持久化 的概念。
对象关系不匹配
在使用 关系型 数据模型的时候，通常会在应用代码中存在一层用于匹配业务代码的转换逻辑，这被称为 impedance mismatch.
使用 非关系型 数据模型可以在一定程度上减少一对多模型这种不匹配。
然而面对 多对一 和 多对多 关系时，文档型数据模型仍然不好处理。
主要区别
- 关系型
提供良好的JOIN支持，对 多对一 和 多对多 的支持 - 文档型
没有模式的约束，由本地性带来的性能提升，以及部分解决了 对象关系不匹配 的问题。
文档型使用场景
当你的应用具有文档类型的结构（比如，是一组一对多关系组成的树状结构）的时候，使用文档型数据模型看起来是明智的选择。
但是，使用文档型数据模型有这些缺陷：
- 当文档嵌套太深时，查询路径会变得很长；
- 当业务场景需要多对多关系时，业务代码会变得臃肿且性能会收到影响。
文档型数据模型的 Schema-free 特性
可以将数据库的 Schema 按下面的方式分类：
schema-on-read: 数据的结构是隐式的，只有在被读的时候才产生影响；
当相同字段的数据具有不同类型的时候，这种方式是适合的。schema-on-write: 数据的结构是显示的，在数据被写的时候数据库会确保数据的格式正确性。
当数据的类型是固定的，这种方式是合适的。
数据本地性
一篇文档通常被存储为以 JSON, XML 或者二进制为编码格式的单个连续的字符串，当需要整篇文档的时候，文档型具有存储本地性的性能优势。
需要注意的是，本地性的优势只有当需要一篇文档的大部分的时候才能体现。
由于对文档的任何修改通常都会对整篇文档重写，因此通用的建议是：把文档尽可能地组织得小。
另外，在一些关系型数据库中，为了数据本地性把一些相关的数据聚合在一起的方式同样存在。例如 列簇 （Cassandra, HBase）的概念就是基于管理数据本地性的。
在未来，关系型和非关系型数据库的混用可能才是常态。
数据查询
指令式语言：让计算机以固定顺序执行某些操作。
声明式语言：只需声明想要的数据的条件。
MapReduce查询
MapReduce既不是指令式也不是声明式，更像是处于两者之间的一种查询。
查询的逻辑以代码片段的形式表示，这些代码会被处理框架重复地调用执行。
类图数据模型
当数据类型多数都是多对多关系时，使用图形数据结构更加自然合理。
图包含：点和边。
典型的图数据模型包括：
社交图：
点：人；
边：描述人与人之间的关系网络图：
点：网页
边：网页中的链接交通图：
点：交汇点
边：路径