1 数据模型
1.1 层次模型
层次模型用树形结构来表示各类实体以及实体间的联系。
层次模型只能直接表示一对多（包括一对一）的联系。
层次模型表示多对多的联系，必须首先将多对多联系分解成一对多联系。
分解方法有两种：冗余结点法和虚拟结点法。
- 冗余节点法： 通过增设两个冗余结点将多对多联系转换成两个一对多联系
- 优点：结构清晰，允许结点改变存储位置
- 缺点：需要额外占用存储空间，有潜在的不一致性
- 虚拟节点法： 将冗余结点换为虚拟结点，所谓虚拟结点就是一个指针，指向所替代的结点。
- 优点：减少对存储空间的浪费，避免产生潜在的不一致性
- 缺点：结点改变存储位置可能引起虚拟结点中指针的修改
层次数据库的存储结构：
- 邻接法：按照层次树的前序穿越的顺序把所有记录值依次邻接存放，即通过物理空间的位置相邻来体现层次顺序。
- 链接法：
- 子-兄弟链接法：每个记录增加两个指针，分别指向最左边的子节点和最近的兄弟节点。
- 层次序列链接法：每个记录增加一个指针，按照树的前序穿越顺序链接各记录值。
1.2 键值存储（Key/Value Store）
KV数据模型可能是最简单的模型，它用于表示二元关系：(key, value)。
如果应用程序需要记录多个字段，那么KV存储可能不是一个好方案。
文档数据库和列族数据库本质上都是KV存储：
- 文档数据库：key是其自动生成的唯一键
_id，值是支持嵌套的json文档。 - 列族(宽列)数据库：key是唯一标识当前行的唯一键（例如t{tableID}_r{rowID}），值是只支持一级嵌套的json文档。
1.3 数组数据库（Array Database）
时序、向量和空间数据库都属于数组数据库：
- 时序：
(时间戳, "事件描述", [数值1, 数值2, ...]) - 向量：
(标题，日期，作者，[嵌入向量])(标题，日期，作者，[嵌入向量]) - 空间：
(纬度，经度，时间，[值向量])(纬度，经度，时间，[值向量])
SQL:1999引入了对单维、固定长度数组的有限支持。
SQL:2003扩展到支持没有预定义最大基数的嵌套数组。
SQL:2023标准包括了对真正的多维数组（SQL/MDA）的支持。这个更新允许SQL使用基于整数的坐标来表示具有任意纬度的数组。
1.4 图数据库（Graph database）
与关系分析中的查询不同，图分析查询包括最短路径、cut set、clique determination等操作。
其实，关系模型是可以描述图的：
- 节点：(node_id, node_data)
- 边缘：(node_id_1, node_id_2, edge_data)
但是原生SQL不足以满足图查询，因此需要多个客户端-服务器往返来执行遍历操作。
SQL:2023引入了属性图查询（SQL/PGQ），用于在关系数据库管理系统中定义和遍历图。
2 数据库系统选型
数据库产品有一个非常重要的特点：一个产品要真的有竞争力，绝对不是说用一点新的设计理念，就能够设计出来的。
我举个例子，谷歌做了个spanner，还把它云化成了产品，理念够先进了吧，全球提交事务，用上原子钟黑科技，so what?
现在谷歌的这个云产品还有人用么？相反的BigQuery这个产品作为一个数仓产品，喜欢的人不要不要的，用的人多的很。
为什么会这样？说白了，数据库产品有这么几个特点：
- 基础理论很成熟，相关的信息，很公开，论文里面都有。
- 对工程能力要求极高。这东西很多时候，就是时间打磨出来的。
任何所谓设计理念先进的产品，在现实面前都是狗屎。数据库是一个非常需要应用场景慢慢打磨的东西。
几乎所有的数据库厂商，在现实的业务负载面前，多多少少都需要经历过很多发现问题，解决问题，发现问题继续解决问题的过程。
一个成熟的数据库产品，需要打磨的时间，需要实践过的业务场景，那是巨大的。
没有这个基础的数据库产品，是不是在商业上真的有价值，我觉得非常打问号，所以Spanner这个东西，就是一个不成熟的产品，没价值。
本文发表于 0001-01-01，最后修改于 0001-01-01。
本站永久域名「 jiavvc.top 」，也可搜索「 后浪笔记一零二四 」找到我。
