数据仓库和事务数据库不一样的地方,在于数据仓库需要对历史数据进行分析。而在数据仓库海量的数据里,如何既节约存储空间,又能满足对历史变更数据的查询,就成为一个要解决的问题。这时候就可以使用拉链表来完成这种需求。
什么是拉链表
以订单这种场景为例,原始订单表orders有如下几个字段:订单ID、创建时间、修改时间、订单状态
4月1号当天的订单
orderid | createtime | modifiedtime | status |
---|---|---|---|
1 | 2018-04-01 | 2018-04-01 | create |
2 | 2018-04-01 | 2018-04-01 | create |
3 | 2018-04-01 | 2018-04-01 | create |
4月2号当天的订单表数据
orderid | createtime | modifiedtime | status |
---|---|---|---|
1 | 2018-04-01 | 2018-04-02 | paid |
2 | 2018-04-01 | 2018-04-02 | finish-closed |
3 | 2018-04-01 | 2018-04-02 | paid |
4 | 2018-04-02 | 2018-04-02 | create |
这一天,订单1、3由create变成paid状态,订单2由create变为paid,然后变为finish状态(假设现在只关心订单的最新状态),订单4为新订单。
这时候,在数据仓库中,可以设计一张表来保存每天的订单变化情况。增加两个字段:dw_start_date
和dw_end_date
,dw_start_date
表示该条记录的生命周期开始时间,dw_end_date
表示该条记录的生命周期结束时间。现在表就变成了下面这个样子:
orderid | createtime | modifiedtime | status | dw_start_date | dw_end_date |
---|---|---|---|---|---|
1 | 2018-04-01 | 2018-04-01 | create | 2018-04-01 | 2018-04-01 |
1 | 2018-04-01 | 2018-04-02 | paid | 2018-04-02 | 9999-12-31 |
2 | 2018-04-01 | 2018-04-01 | create | 2018-04-01 | 2018-04-01 |
2 | 2018-04-01 | 2018-04-02 | finish-closed | 2018-04-02 | 9999-12-31 |
3 | 2018-04-01 | 2018-04-01 | create | 2018-04-01 | 2018-04-01 |
3 | 2018-04-01 | 2018-04-02 | paid | 2018-04-02 | 9999-12-31 |
4 | 2018-04-02 | 2018-04-02 | create | 2018-04-02 | 9999-12-31 |
这个表就叫拉链表 orders_his