数据库表设计 到 dataware house 表设计 --- 拉链表

今天来说说其中的一种big data设计的表类型，拉链表。

首先的说说拉链表到底是个什么东西，DB 一般听到一种表，可能会联想到某种物理方面的技术，如临时表， template table , 继承表，等等， 今天的拉链表本身不是一项物理技术，而是一种逻辑技术。通过某种设计，来达到某些目的的，人为的方法。

拉链表在什么地方用，显然严格的说拉链表是要用到在 BIG DATA ，data warehouse 这一类的地方是他的起源，当然可以在研究将其用到 DB 中的某些设计（今天就不说了）。

在BIG DATA中，有一种需求是要根据各种维度，对历史时期的数据进行处理，而达到一个历史数据统计分析的目的，而这就会出现一个问题，数据量的问题。我们举一个例子，我们有一个用户的加入购物车物品的数量记录表，（后面简称购物车表）客户可能今天将一些产品放到购物车，而过了些日子就将他们删除了，当然其中的原因只能是客户自己知道，而公司是不是要通过这样的变化来找点什么事情做，要不闲着闲着就下岗了。通过购物车的历史变化而可以得出很多维度的信息，让后就可以去促销，当然也可以和XX公司来个杀熟。

OK 废话了那么多，拉链表的有一个定义吧

一个通过记录历史数据，并将其变化的状态进行体现，压缩存储空间，方便进行历史同期分析，或阶段性分析的数据存储和处理的方式就可以叫拉链表。

而叫拉链表也是有原因的， 1 存储了开始和结束的时间（针对每行记录和业务逻辑绑定） 2 开始和结束的时间收尾相接，形成链式机构 3 避免存储每天的全量记录。

举例：我们要统计每个月客户在自己的购物车添加的东西的数量和删除的数量。（至少我们可以知道他们的购买的欲望和钱包之间的可能的关系）

以MPP架构为例

1 当月第一天的前一天的购物车表的全量数据

全量数据表中包含至少3非业务数据的字段，开始时间 和 结束时间，开始时间可以是记录导入到data warehouse 的时间，也可以是本身记录在业务表插入的时间，具体的和业务分析以及你拥有的资源挂钩， 以及记录最后一次的操作方式 I D U。

2 进行当月天数的拉链表分区表的设计，分区键一般是 可以是开始时间，或符号业务逻辑的字段

3 通过某些手段获取第二天变化过的购物车表的记录，并存储进临时表

将第二天业务表中，插入的，UPDATE ，delete 的操作（有可能是逻辑操作，这里假设是物理操作） I D U 三种操作

4 通过之前一天的数据变化历史表，与当天记录的历史的变化数据进行 left join 运算，然后得出当天 Delete 和 update 的操作记录以及没有变化的记录，然后在加上当天insert 操作的记录，就得到了第二天的整体的业务表。

5 通过这样的方式可以得到一整个月的数据变化，（也可以在DATA WAREHOUSE 的 业务历史表根据记录行的最后一次的操作状态（可以是物理，也可以是逻辑），来将已经删除的记录排除到下一次数据的历史分区表之外）

通过这样的方法，就可以将一个月所有客户的购物车的变化曲线图，或者删除的最多的产品，在或者某个地域删除购物车，或某类产品被添加的购物车的当天，当月最大量等等都统计和分析出来。

这样做的好处

1 我们是否可以将每天的数据都同步到 数据仓库一次，答案是当然，但问题

1.1 购物车是动态的，同步数据的时候虽然可以使用从库等进行数据的抓取，但数据量大的情况，处理起来还是比较笨拙的。同时数据量的问题不知道是否考虑过，每天一个全量的业务表.......

好处： 拉链表通过获取变动的数据来进行数据的生成，这明显降低了业务系统的压力，以及网络，存储等多系统的负担，大部分工作在数仓本身就完成了

1.2 数据量的问题，虽然根据上面的方法，已我们有10亿条记录，每天更改的记录在200万，则我们需要存储的记录的数字（以30天为例）， 200万* 29天 + 1天 10亿，针对上面的每天一个切片的方式存储的数据量对比 30天* 10亿 + 要节省很多存储空间。

举例这是我们12月1 日的全量表

下面地记录就是拉链表，其中记录了每条记录地在每天地变化，通过初始表+拉链表，可以将这一个月地所有地数据变化进行相关维度地分析，或生成新的时间维度的数据表。

在学习这方面知识的同时，DW在表设计这方面要灵活，相关方法也很多，当然学习中可能就会通过不断的深入而发现之前的一些失误，如您发现还请指正，感谢。

另外在上面的学习中其中有一个漏洞，不知道您看出来了没有