数据模型和查询语句

数据模型不仅会影响我们如何编写代码,更重要的是,它会指导我们如何思考正在处理的问题

绝大部分应用的构建都可以抽象成一层数据模型叠加在另一层之上,因此,如何表现每一层的数据成为了关键点。

层级数据模型的基本点在于:每一层都应该隐藏自己的复杂度并向外提供干净的数据模型。

关系型 vs 文档型

不同类型的应用可能需要不同类型的数据模型,在可预见的未来,应该是 关系型数据 的大量使用伴随着其他 非关系型数据 的应用,也就是所谓的 混合型持久化 的概念。

对象关系不匹配

在使用 关系型 数据模型的时候,通常会在应用代码中存在一层用于匹配业务代码的转换逻辑,这被称为 impedance mismatch.

使用 非关系型 数据模型可以在一定程度上减少一对多模型这种不匹配。

然而面对 多对一多对多 关系时,文档型数据模型仍然不好处理。

主要区别

  • 关系型
    提供良好的 JOIN 支持,对 多对一多对多 的支持
  • 文档型
    没有模式的约束,由本地性带来的性能提升,以及部分解决了 对象关系不匹配 的问题。

文档型使用场景

当你的应用具有文档类型的结构(比如,是一组一对多关系组成的树状结构)的时候,使用文档型数据模型看起来是明智的选择。

但是,使用文档型数据模型有这些缺陷:

  • 当文档嵌套太深时,查询路径会变得很长;
  • 当业务场景需要多对多关系时,业务代码会变得臃肿且性能会收到影响。

文档型数据模型的 Schema-free 特性

可以将数据库的 Schema 按下面的方式分类:

  • schema-on-read: 数据的结构是隐式的,只有在被读的时候才产生影响;
    当相同字段的数据具有不同类型的时候,这种方式是适合的。

  • schema-on-write: 数据的结构是显示的,在数据被写的时候数据库会确保数据的格式正确性。
    当数据的类型是固定的,这种方式是合适的。

数据本地性

一篇文档通常被存储为以 JSON, XML 或者二进制为编码格式的单个连续的字符串,当需要整篇文档的时候,文档型具有存储本地性的性能优势。

需要注意的是,本地性的优势只有当需要一篇文档的大部分的时候才能体现。
由于对文档的任何修改通常都会对整篇文档重写,因此通用的建议是:把文档尽可能地组织得小。

另外,在一些关系型数据库中,为了数据本地性把一些相关的数据聚合在一起的方式同样存在。例如 列簇 (Cassandra, HBase)的概念就是基于管理数据本地性的。

在未来,关系型和非关系型数据库的混用可能才是常态。

数据查询

指令式语言:让计算机以固定顺序执行某些操作。
声明式语言:只需声明想要的数据的条件。

MapReduce查询

MapReduce既不是指令式也不是声明式,更像是处于两者之间的一种查询。

查询的逻辑以代码片段的形式表示,这些代码会被处理框架重复地调用执行。

类图数据模型

当数据类型多数都是多对多关系时,使用图形数据结构更加自然合理。

包含:点和边。

典型的图数据模型包括:

  • 社交图:
    :人;
    :描述人与人之间的关系

  • 网络图:
    :网页
    :网页中的链接

  • 交通图:
    :交汇点
    :路径

其他详细图形数据库