DDIA读书笔记 | 第二章：数据模型与查询语言

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

数据模型和查询语言，即程序员将数据录入数据库的格式，以及再次要回数据的机制

在历史上，数据最开始被表示为层次数据模型，但是这不利于表示多对多的关系，所以发明了关系模型来解决这个问题。最近，开发人员发现一些应用程序也不适合采用关系模型。新的非关系型“NoSQL”数据存储在两个主要方向上存在分歧：

1.文档数据库的应用场景是：数据通常是自我包含的，而且文档之间的关系非常稀少。
2. 图形数据库用于相反的场景：任意事物都可能与任何事物相关联。

---

一、数据模型

1. 关系模型

适合联结，描述一对多、多对一、多对多关系。

• 数据规范化
• • 各种id，对人无意义，所以不需要变更。

  2. 文档模型

  数据模型

  JSON模型（JSON比XML更简单。面向文档的数据库（如MongoDB ，RethinkDB ，CouchDB 和 Espresso）支持这种数据模型）

  特性

• 适合一个文档和其他文档**关联很少**的场景。
• 应用程序大多数的关系是一对多关系（树状结构化数据），或者大多数记录之间不存在关系，那么使用文档模型是合适的。

• 优点

  • 较好的模式灵活性。不强制执行模式，数据可同时包含新旧模式，增加字段较方便。
  • 较好的局部性。适合同时访问文档大部分内容的场景。

  文档模型中的模式灵活性

• 大多数文档数据库以及关系数据库中的JSON支持都不会强制文档中的数据采用何种模式。
• 在“静态类型”数据库模式中，通常会执行迁移操作：
• • 大多数关系数据库系统可在几毫秒内执行ALTER TABLE语句。MySQL是一个值得注意的例外，它执行ALTER TABLE时会复制整个表（大型表格时会比较耗时）
  • 大型表上运行UPDATE语句在任何数据库上都可能会很慢，因为每一行都需要重写。要是不可接受的话，应用程序可以将first_name设置为默认值NULL，并在读取时再填充，就像使用文档数据库一样。

  缺点

  • 不能直接引用文档中的嵌套的项目，而是需要说“用户251的位置列表中的第二项”（很像分层模型中的访问路径）。但只要文件嵌套不太深，这通常不是问题。
  • 文档数据库对连接的糟糕（多对多关系的时候）

  3. 图模型

  适合所有用例都可能产生多对多关系的场景

• 属性图。顶点包含出入边，联结范围可预知。
• • Cypher查询语言：声明式查询语言
• 三元组
• • SPARQL

  二、数据查询语言

  1.声明式

  分层思想，使用方便，隐藏实现细节，可无感知升级

• js选择器

• 2. 命令式

• js DOM

• 3. MapReduce查询

• MapReduce既不是声明式的查询语言，也不是一个完全命令式的查询API，而是处于两者之间：**查询的逻辑用代码片段来表示，这些代码片段会被处理框架重复性调用**。它基于map（也称为collect）和reduce（也称为fold或inject）函数，两个函数存在于许多函数式编程语言中。
• map和reduce函数在功能上有所限制：它们必须是纯函数，这意味着它们只使用传递给它们的数据作为输入，它们不能执行额外的数据库查询，也不能有任何副作用。这些限制允许数据库以任何顺序运行任何功能，并在失败时重新运行它们。然而，map和reduce函数仍然是强大的：它们可以解析字符串，调用库函数，执行计算等等。