关于电商平台数据版本化的思考

        通常做电商类系统都会遇到类似的问题，为了便于理解，下面通过一个小故事来梳理一下：

        小明在平台开了一家店，发布了一件商品(一双女鞋)，小芳在浏览店铺时看见了这双鞋子，立马下单购买了，这时就会产生一条订单，它至少包含下面几大要素：

       一天后小明觉得女鞋不好卖，他想把店里的女鞋换成男鞋，于是他直接编辑了原来的女鞋商品，图片/介绍/价格都做了调整。正好这个时候小芳登录平台想看看自己买的鞋子发货没有，结果小芳惊呆了，自己明明买的女鞋怎么变成了男鞋，她马上打电话给平台反映了此事，客服小美找到了技术部门的小猿并质问他为什么会这样， 小猿一脸懵逼，他想我在订单表里存了商品id，查看订单时通过商品id把商品详情带出来，这个逻辑没错啊，下面是小猿设计的表结构

        这时产品经理小P听到了争执，在了解情况后，他觉得这个问题必须解决，否则平台以后会官司缠身，于是他拉上开发部的小伙伴们开始商量解决方案，技术部比较资深的大猿提出了下面几个方案：

        方案一：在每条订单记录里使用json保存购买时商品的信息。这样小芳每次查看订单，看到的都是购买时的商品信息，小猿在查询订单时也不用关联商品表获取商品信息了。

小P：如果以后想要在订单里保存的商品json对象种增加信息是不是要找小猿手工去处理？

小猿：去死吧，这个活我不干！你们产品就不能先把字段都想好吗？

小P：我要有那本事还会在这吗？我可是打算和平台一起成长的...

小威(前端开发)：如果以后产品数据结构调整，我的前端页面和订单里保存的商品数据结构不一致怎么办，我是不是要维护很多不同版本的商品信息页？

大家：......

       方案二：每次修改商品信息时都将原商品信息复制一条，然后在复制的商品记录上进行修改，相当于新增一条商品信息，但是这两条商品信息的编码保持一致，这样才能识别它们是同一个商品的不同版本。小明店铺里显示的始终是最新版本的商品，小芳订单里关联的是修改前的version为1的商品id。

小猿和小威：这个方案好，我们也不用担心不同版本的商品结构不一致了，因为都在一张表里。

小P：如果用户修改了商品关联的类目名称呢？

小猿：那类目表也做版本啊

小P：如果用户又修改了商品关联的颜色或其它属性呢？

小猿：你就不能把这些可能关联的都固定好吗？

小P：我不是还在成长吗......

小猿：其实还有一个问题，如果用户频繁的编辑商品，这张表的体积会增加的非常快，但可能大部分数据都没有保存的价值。

大家：......

        方案三：由订单成交来拉动商品的版本更新。旧版本的商品存入历史商品表中，结构与主商品表基本一致，但是同时将一些关键属性(比如类目/颜色等)的id和值同时保存，尽量缩小版本化的范围。

1、订单表由关联商品表的id改为关联历史商品表的id

2、版本化流程

小猿：这个方案更好，这样版本化的次数可以控制到最低。历史商品表可以针对订单需求进行设计，不用局限于商品表的结构。

小威：拜托结构不要差别太大，我还想复用商品详情界面的组件呢。

小P：应该会比用户购买前看到的商品详情界面简单吧。大猿，历史商品表是不是保存商品所有关联信息？

大猿：不需要，可以根据业务需要逐步添加。

小P：如果新加的字段在已经版本化的记录里没有，要怎么补救呢？

大猿：历史商品表的数据主要有两个用处，第一是交易存证，在交易发生纠纷时，可使用订单关联的历史商品数据进行佐证。第二用于统计分析，例如需要通过商品的不同维度(类目/颜色/尺码....)去统计交易量/交易额等。因此从这两点需求出发，大致可以确定哪些字段需要保存。小P，快点成长吧！

大家：干活去咯！

----------------故事结束------------

不知你是否看懂，如果没有看懂或者有更好的方案，欢迎交流！