这一章在做什么

读之前：先预测

第 1 章区分了记录系统和派生数据，第 2 章用社交网络的时间线讲了「物化」：预先把查询结果算好，写的时候多干活，读的时候省事。这一章往前退一步，问数据本身该存成什么样子，第 2 章那条时间线会在 §1.2 再出现一次。下一章（第 4 章）讲这些模型在磁盘上怎么实现；第 5 章接着讲模式怎么随时间演化；§3 的事件日志和物化视图，到第 12 章讲流处理时还会接着讲。

1. 一对多、多对一、多对多，哪一种开始让文档模型吃力？关系模型怎么应付它？§1.3
2. 存 ID 和直接存一份文字，各在读和写的哪一边付代价？§1.2
3. 同一个查询，为什么在图查询语言里几行，在 SQL 里要写几十行？§2.3
4. 事件溯源为什么要求事件不可变、而且按固定的顺序处理？§3

这一章的骨架

这一章是一次巡礼：先用很长的篇幅比较关系模型和文档模型（§1），再看图模型和查它的五种语言（§2），最后是两样不太一样的东西：把写和读拆开的事件溯源（§3），以及分析和科学计算里用的数据框与矩阵（§4）。容易乱的是 §2：几种语言轮流查同一个例子，读的时候抓住每一种比前一种多了什么、少了什么，语法不用记。

边读边填：每行一个问题，读到答案就写一两句。只存在你这台设备的浏览器里，别人看不到。

分节地图

全章约 1.4 万词（不算代码和图注），建议分四次读。第一、二次是关系模型和文档模型的长篇比较；第三次是图，代码多、正文少，读得比词数快；第四次是事件溯源和数据框，彼此独立。

1. 第一次坐下§0–§1.2 · 约 3400 词 · 分层、ORM、存 ID 还是抄一份
2. Data models are perhaps the most…约 600 词开篇数据模型一层叠一层，每层藏住下面的复杂性。方框里讲什么叫声明式查询语言。
3. Relational Versus Document Models约 400 词关系模型与文档模型关系模型的对手来了又走；NoSQL 留下的持久影响之一是文档模型。
4. The Object-Relational Mismatch约 1000 词对象与关系的错位ORM 的毛病和好处、N+1 查询；一对多的数据为什么适合装进一个文档。
5. Normalization, Denormalization, and Joins约 1400 词规范化、反规范化与连接存 ID 还是存文字，两边的代价；回到第 2 章的时间线，看「只存 ID」的折中。
6. 第二次坐下§1.3–§1.5 · 约 2800 词 · 关系的类型、分析用的模式、两派怎么选
7. Many-to-One and Many-to-Many Relationships约 400 词多对一与多对多这两种关系为什么塞不进一个文档；两个方向都要查时靠什么。
8. Stars and Snowflakes: Schemas for Analytics约 800 词星型与雪花：分析用的模式事实表和维度表；数据仓库里的反规范化为什么不成问题。
9. When to Use Which Model约 1600 词什么时候用哪种模型文档模型的长处和局限、读时模式与写时模式、局部性、两派合流。这一块的重心。
10. 第三次坐下§2–§2.6 · 约 4700 词 · 图模型和查它的几种语言
11. Graph-Like Data Models约 600 词图状的数据模型多对多多到什么程度该用图；一张图里可以放完全不同种类的东西。
12. Property Graphs约 600 词属性图顶点和边各由什么组成；用两张关系表也能存下一张图。
13. The Cypher Query Language约 500 词Cypher 查询语言用箭头画出要找的模式；同一个查询可以从哪一头开始执行。
14. Graph Queries in SQL约 500 词用 SQL 查图不知道要走几条边时，SQL 得用递归查询。对比两边的行数。
15. Triple Stores and SPARQL约 900 词三元组存储与 SPARQL主语、谓语、宾语；RDF 为什么用 URI；语义网留下了什么。
16. Datalog: Recursive Relational Queries约 800 词Datalog：递归的关系查询用一条条规则推出新的虚拟表，规则可以调用自己。跟着推导走一遍。
17. GraphQL约 700 词GraphQL 查询语言一种故意受限的语言：给客户端用，不许递归，响应里有重复也认了。
18. 第四次坐下§3–§5 · 约 3100 词 · 事件溯源、数据框，加小结
19. Event Sourcing and CQRS约 1700 词事件溯源与 CQRS写成不可变的事件日志，读从它派生的物化视图；好处一串，麻烦也一串。
20. DataFrames, Matrices, and Arrays约 800 词数据框、矩阵和数组数据科学家怎样一步步把表变成矩阵；独热编码；数组数据库。
21. Summary约 700 词小结全章回顾，外加几种没讲到的模型。先自己回忆一遍再读它。

先用中文过一遍

关系的形状：一对多放进文档，多对多要靠引用

拿一个菜谱 App 来想。一道菜谱有好几个步骤，每个步骤只属于这道菜：这是一对多，整份数据是一棵树。存成一个 JSON 文档最自然，打开菜谱时一次读出全部内容，不用拼。存进关系数据库，就要拆成菜谱表、步骤表，读的时候再按菜谱 ID 拼回来。

再看作者和食材。很多菜谱是同一个作者写的，这是多对一；一道菜用好几种食材，一种食材出现在很多道菜里，这是多对多。把作者的资料、食材的说明抄进每个菜谱文档，改一处就得改一大片，所以文档里只存它们的 ID，指向别的文档。到这一步，文档模型也离不开「按 ID 去找另一条记录」，也就是连接。关系模型处理多对多的标准做法，是一张关联表：每一行把一个菜谱 ID 和一个食材 ID 连起来，两列各建一个索引，两个方向都能查。

存 ID 还是抄一份：规范化和反规范化

公司内部的工单系统，每张工单要显示负责人的名字。可以只存员工 ID，显示时再按 ID 查名字；也可以把名字直接抄进工单里。前一种叫规范化：给人看的信息只存一处，别处都用一个对人没有意义、所以永远不用改的 ID 去引用。员工改了显示名，改一行就完了，代价是每次读工单都要多查一次（关系数据库里是连接，在应用代码里按 ID 查回来叫「补全」）。后一种叫反规范化：读的时候直接拿到，但改名要改所有副本，漏改一张，数据就前后不一了。

这和第 2 章的物化是一回事：反规范化的副本是派生数据，你得有一套机制在原数据变了以后去更新它们。书里还讲了一种折中：预先算好的列表里只存 ID，读的时候再补全。哪些东西抄、哪些只存 ID，要看它变得多快、读写各有多贵。

图：顶点、边，和不知道要走几步的查询

多对多的关系一多，而且各种东西互相连着，用图更自然：每样东西是一个顶点，每个关系是一条边。属性图模型里，顶点和边都带一个标签（「这是文件夹」「这是编辑过」）和一组键值属性。任何顶点都能连向任何顶点，一张图里可以同时放人、文件、文件夹、标签。

图查询难在路径的长度事先不知道。拿网盘来说：「小周编辑过的文件里，哪些在共享盘『项目资料』下面？」文件可能直接在共享盘里，也可能隔了三层子文件夹。图查询语言可以写「沿着『在……里面』的边走一次或多次」；关系数据库的每走一条边就是一次连接，连接的次数不固定，就得用递归查询（WITH RECURSIVE）：从根开始一轮轮往下展开，直到没有新的为止。

用属性图的查询语言（这里按 Cypher 的写法）大概是这样，*1.. 的意思是这条边走一次或多次：

MATCH (u:User {name: '小周'}) -[:EDITED]-> (f:File)
      -[:IN*1..]-> (:Folder {name: '项目资料'})
RETURN f.name

同一件事，顶点存在 items 表、边存在 links 表，用 SQL 的递归查询写：

WITH RECURSIVE under(id) AS (
    SELECT id FROM items WHERE kind = 'folder' AND name = '项目资料'
  UNION
    SELECT l.src FROM links l JOIN under ON l.dst = under.id
    WHERE l.kind = 'in'
)
SELECT f.name
FROM items f
JOIN under ON f.id = under.id
JOIN links e ON e.dst = f.id AND e.kind = 'edited'
JOIN items u ON u.id = e.src AND u.name = '小周'
WHERE f.kind = 'file';

这两段是本站写的。书里用另一个例子，把同一个查询分别用 Cypher、SQL、SPARQL、Datalog 写了一遍，读的时候留意行数差多少，以及 Datalog 怎么把递归拆成两条规则。

事件溯源：先记下发生了什么，读的样子另外算

前面几种模型，写进去的形状就是读出来的形状。事件溯源把两者拆开：写的时候只往一个日志末尾追加事件，每个事件用过去时说一件已经发生的事（「书已借出」「书已归还」），写进去就不再改、不再删；读的时候不查日志，而是查从日志派生出来的物化视图，每个视图为一类查询优化。这种「写一种表示、读另几种表示」的做法叫 CQRS。

用户的请求先是一个「命令」，校验通过了才变成事件写进日志，所以日志里只有有效的事件，下游的视图不能拒收。视图随时可以删掉，按同样的顺序、用同样的代码把事件重放一遍，就能重新算出来；这要求处理事件的逻辑是确定的，重放时也不能重复做发短信这类对外的动作。

这一章点名的系统

词与短语

词条按在书里出现的顺序排，按节分组；读一节之前先把这一节的过一遍，读的时候就不用停。斜体小字是原句里连续的几个词，在电子书里搜它就能找到那一句。标着「每个字都认识」的，是字面意思会把你带偏的。行话（normalization、schema-on-read 这类）不在这里，在上面的术语表里。

§0 Data models are perhaps the most…

§1 Relational Versus Document Models

§1.1 The Object-Relational Mismatch

§1.2 Normalization, Denormalization, and Joins

§1.4 Stars and Snowflakes: Schemas for Analytics

§1.5 When to Use Which Model

§2.1 Property Graphs

§2.2 The Cypher Query Language

§2.3 Graph Queries in SQL

§2.4 Triple Stores and SPARQL

§2.5 Datalog: Recursive Relational Queries

§2.6 GraphQL

§3 Event Sourcing and CQRS

§4 DataFrames, Matrices, and Arrays

§5 Summary

读完：回到你的预测

判断题：换成你来选

场景都是本站编的。先选，再看解释；解释里写了对应的节号，拿不准就回原书看那一节。

和本站其他书对照

值得停下来的句子

Document databases are sometimes called schemaless, but that’s misleading as the code that reads the data usually assumes some kind of structure— §1.5。本站译：文档数据库有时被称为「无模式」的，但这个说法有误导性：读数据的代码通常都假定了某种结构。

值得停，是因为它把一场常见的争论换了个问法。问题从来不是「要不要模式」，而是模式写在哪里、由谁来保证：写时模式由数据库在写入时把关，读时模式散落在每一段读数据的代码里。书里拿它类比静态类型和动态类型，两边各有拥护者。读到第 5 章的模式演化时，这句话还会派上用场。

You should always be able to delete the materialized views and recompute them by processing the same events in the same order…— §3。本站译：你应该随时可以删掉物化视图，按同样的顺序处理同样的事件，把它们重新算出来……

事件溯源的好处，几乎都从这一条长出来：视图有 bug 就删掉重算，想换个方式展示就再派生一个视图。它的麻烦也都是为了守住这一条：处理逻辑必须确定（不能现取汇率），日志的顺序必须固定，重放时不能再触发对外的动作。第 12 章讲流处理时，会回到事件日志和物化视图这个话题。

检查一下理解

用一句话说这一章（写给一个没读过的朋友）：

精彩回顾

一句话：选数据模型，先看数据之间的关系长什么样：树用文档，多对多靠引用和连接，四通八达用图；写和读的形状不同，就把它们拆开。