在有些情况下，为了保持历史的一些状态，需要用拉链表来做，这样做目的在可以保留所有状态的情况下可以节省空间。
拉链表适用于以下几种情况吧
数据量有点大，表中某些字段有变化，但是呢变化的频率也不是很高，业务需求呢又需要统计这种变化状态，每天全量一份呢，有点不太现实，
不仅浪费了存储空间，有时可能业务统计也有点麻烦，这时，拉链表的作用就提现出来了，既节省空间，又满足了需求。
一般在数仓中通过增加begin_date,en_date来表示，如下例，后两列是start_date和end_date.
1 2 3 4 5 6 7 8 9 10 | 1 2016-08-20 2016-08-20 创建 2016-08-20 2016-08-201 2016-08-20 2016-08-21 支付 2016-08-21 2016-08-211 2016-08-20 2016-08-22 完成 2016-08-22 9999-12-312 2016-08-20 2016-08-20 创建 2016-08-20 2016-08-202 2016-08-20 2016-08-21 完成 2016-08-21 9999-12-313 2016-08-20 2016-08-20 创建 2016-08-20 2016-08-213 2016-08-20 2016-08-22 支付 2016-08-22 9999-12-314 2016-08-21 2016-08-21 创建 2016-08-21 2016-08-214 2016-08-21 2016-08-22 支付 2016-08-22 9999-12-315 2016-08-22 2016-08-22 创建 2016-08-22 9999-12-31 |
begin_date表示该条记录的生命周期开始时间，end_date表示该条记录的生命周期结束时间；
end_date = ‘9999-12-31’表示该条记录目前处于有效状态；
如果查询当前所有有效的记录，则select * from order_his where dw_end_date = ‘9999-12-31′
如果查询2016-08-21的历史快照，则select * from order_his where begin_date <= ‘2016-08-21′ and end_date >= ‘2016-08-21’
再简单介绍一下拉链表的更新：
假设以天为维度，以每天的最后一个状态为当天的最终状态。
以一张订单表为例，如下是原始数据，每天的订单状态明细
1 2 3 4 5 6 7 8 9 10 | 1 2016-08-20 2016-08-20 创建2 2016-08-20 2016-08-20 创建3 2016-08-20 2016-08-20 创建1 2016-08-20 2016-08-21 支付2 2016-08-20 2016-08-21 完成4 2016-08-21 2016-08-21 创建1 2016-08-20 2016-08-22 完成3 2016-08-20 2016-08-22 支付4 2016-08-21 2016-08-22 支付5 2016-08-22 2016-08-22 创建 |
根据拉链表我们希望得到的是
1 2 3 4 5 6 7 8 9 10 | 1 2016-08-20 2016-08-20 创建 2016-08-20 2016-08-201 2016-08-20 2016-08-21 支付 2016-08-21 2016-08-211 2016-08-20 2016-08-22 完成 2016-08-22 9999-12-312 2016-08-20 2016-08-20 创建 2016-08-20 2016-08-202 2016-08-20 2016-08-21 完成 2016-08-21 9999-12-313 2016-08-20 2016-08-20 创建 2016-08-20 2016-08-213 2016-08-20 2016-08-22 支付 2016-08-22 9999-12-314 2016-08-21 2016-08-21 创建 2016-08-21 2016-08-214 2016-08-21 2016-08-22 支付 2016-08-22 9999-12-315 2016-08-22 2016-08-22 创建 2016-08-22 9999-12-31 |
可以看出 1，2，3，4每个订单的状态都有，并且也能统计到当前的有效状态。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
