指标是一个统称概念，可以细分为 原子指标和 派生指标。 以 某企业近一周上海地域的销售金额 为例，整体是一个派生指标，其中的 销售金额 是原子指标；近一周 是时间，企业 和 地域 是维度。
可见，指标数据由三部分组成：
- 时间
- 维度
- 数值
其中，维度可以是一个或多个，也可以是零个，简称为多维。
什么是关系型数据库？
典型的关系型数据库就是 MySQL。
使用时，需要先根据业务设计好数据模式：
- 数据库中有哪些数据表
- 数据表中有哪些字段
然后，创建相应的数据库和数据表；最后，存储业务数据。
关系型数据库会有一个特殊的 约定：数据模式是相对固定的。业务不发生变化的情况下，数据模式不会轻易发生变化。
使用关系型数据库存储多维指标数据会有什么问题？
不同的业务会有不同的指标，每一个业务可以单独创建一个数据库，这个比较好理解。
每一个指标都会有时间和数值，但是不同的指标之间，它们的维度名称和维度数目却可能是不同的。
最直接的设计：
- 每一个指标单独创建一个数据表，位于某个业务数据库
- 数据表除时间和数值字段外，根据指标的不同，创建若干维度字段
假设某个指标有三个维度：a、b 和 c，表结构如下所示：
| timestamp | a | b | c | value |
|---|---|---|---|---|
| 2022-09-15 00:00:00 | a1 | b1 | c1 | 1 |
| 2022-09-15 01:00:00 | a2 | b2 | c2 | 2 |
| 2022-09-15 02:00:00 | a3 | b3 | c3 | 3 |
timestamp 表示时间，value 表示数值，a、b 和 c 表示维度。
问题很明显：
- 如果某个业务拥有成千上万个指标，就需要创建成千上万个数据表。无论是预先创建数据表，还是随着指标的新增动态创建新的数据表，如此数目庞大的数据表是不能接受的。
- 固化的数据表结构不能很好地应对指标的维度名称和维度数目发生变化的场景。
受限于业务方的部署环境，仅支持关系型数据库 MySQL；而且业务方不能接收一个业务指标一个数据表的粗暴设计。
思考
业务指标的数目是不可控的，但业务指标的维度数目是相对可控的，我们是否可以按维度数目创建 指标表，毕竟绝大多数数据可视化组件最多支持三维。
比如：
- 维度数目为 0 的指标表
- 维度数目为 1 的指标表
- 维度数目为 2 的指标表
- ...
假设维度数目为 3 的指标表，表结构如下所示：
| id | timestamp | d1 | d2 | d3 | value |
|---|---|---|---|---|---|
| m1 | 2022-09-15 00:00:00 | a1 | b1 | c1 | 1 |
| m2 | 2022-09-15 01:00:00 | a2 | b2 | c2 | 2 |
| m3 | 2022-09-15 02:00:00 | a3 | b3 | c3 | 3 |
id 表示指标 ID，用于唯一标识指标；d1 、d2 和 d3 分别表示维度1、维度2 和 维度3。
一张数据表中可以存储多个相同维度数目指标的数据，如：m1、m2 和 m3。存储指标数据时，只要按指标的维度数目，将指标数据存储到相应维度数目的指标表中即可。指标表可以根据业务可能的最大维度数目预先创建，业务维度数目需要扩展时，仅需要新增有限的几张特定维度数目的指标表即可。
还不够！
指标有维度的情况下，指标表仅支持按指标维度次序，依次存储和查询维度1、维度2、... 的维度数据，并不知道具体的维度名称是什么。
考虑到业务希望指标发生变化时，历史数据可追溯，同一个指标需要有多个版本。
也就是说，我们需要知道：
- 指标的版本有哪些
- 指标的某个版本有哪些维度，维度名称是什么
- 指标的某个版本有哪些数据
我们可以：
- 创建一张 版本表，存储指标有哪些版本
- 创建一张 维度表，存储指标的某个版本有哪些维度（名称）
- 根据维度数目创建若干张指标表，存储指标的某个版本的指标数据
可行！
存储方案
版本表
| id | version |
|---|---|
| m1 | 1 |
| m2 | 1 |
| m1 | 3 |
id 表示指标 ID，version 表示版本号。
版本表存储着指标和版本的对应关系，可以查询指标的历史版本记录，也可以查询指标的最新版本。
维度表
| id | version | name |
|---|---|---|
| m1 | 3 | a1 |
| m1 | 3 | a2 |
| m1 | 3 | a3 |
id 表示指标 ID，version 表示版本号，name 表示维度名称。
维度表存储着指标/版本和维度名称的对应关系，可以按指标 ID 和指标版本查询维度名称列表，多个维度名称的顺序按维度名称存储顺序依次排列。
指标表
| id | version | timestamp | d1 | d2 | d3 | value |
|---|---|---|---|---|---|---|
| m1 | 3 | 2022-09-15 00:00:00 | a1 | b1 | c1 | 1 |
| m1 | 3 | 2022-09-15 01:00:00 | a2 | b2 | c2 | 2 |
| m1 | 3 | 2022-09-15 02:00:00 | a3 | b3 | c3 | 3 |
指标表存储着指标数据。注意，维度1、维度2 和 维度 N 的表现形式。
存储指标数据
新增指标时，使用 Unix 时间戳作为版本号，存储指标 ID 和 版本至版本表；如果指标有维度，存储指标ID、版本号 和维度名称至维度表，如果维度有多个，需要按照维度排列顺序依次存储多条记录。
修改指标时，如果修改后的指标维度名称列表和维度表中该指标最新版本的维度名称列表数目或内容不一致，需要和新增指标一样，存储该指标新的版本号和维度名称列表。
存储指标数据时，获取维度表中该指标最新版本的维度名称列表，即可知指标维度数目；根据维度数目选取指标表，将指标数据存储至该指标表，维度名称需按顺序依次存储至维度1、维度2、...。
查询指标数据
- 根据指标 ID 查询版本表，获取该指标的最新版本号，或者直接指定某个版本号；
- 根据指标 ID 和版本号，查询维度表，获取该指标的维度名称列表和维度数目；
- 根据指标的维度数目，选取指标表；
- 根据指标 ID 和版本号，查询指标表，获取该指标的数据；也可以使用时间或维度过滤指标数据。
- 使用 2 中获取指标的维度名称，替换 4 中获取的指标数据中的维度1（d1）、维度2（d2） 、...。