订单系统的表设计探讨

一，订单系统的最小模型

|===订单信息============|      |=======商品信息====================|======支付信息========|
|订单编号|订单状态|下单时间|用户ID|商家ID|商品ID|款式ID|价格|购买数量|运费|支付金额|支付状态|支付时间|
复制代码

以上包含了一张订单的最基本的信息，我们看到基本信息包含了几大要素和扩展思路

1，用户信息

用户ID用来关联统计用户的购买信息或者限购

核销订单：记录用户的手机号，可建order_contact表，记录用户下单时填充的联系方式

物流订单：记录用户下单时选择的地址信息联系方式，可建order_address表，用来记录用户下单的地址信息，这些都是以下单时刻的信息为准，不能关联ID

2，商品款式信息

物流商品绝大多数都是支持跨商家的多商品的下单的，因此需要在订单表中拆出

订单表
|订单编号|订单状态|下单时间|用户ID|商家ID|商品总金额|运费总金额|支付金额|支付状态|支付时间|
复制代码

订单商品表
|订单ID|商家ID|商品ID|款式ID|价格|购买数量|支付金额|运费金额|
复制代码

3，快照问题

订单快照一般是对应订单中的某个商品的快照记录，是商品纬度的信息，也就是说，如果一个订单下单购买了同一个商品的不同款式，只需要记录一条商品快照即可，一般用mongodb来存储信息，但不同的数据库，也造成了查询表的麻烦，大量的实践经验表明，商品信息，价格信息是查询最常用的几个字段，我们冗余到订单商品表中，改造后为这样：

订单商品表
             |=====商品信息=========|====款式信息==========|   
|订单ID|商家ID|商品ID|商品名称|商品头图|款式ID|款式名称|款式头图|原价|售卖价|下单价格|购买数量|支付金额|运费金额|
复制代码

4，支付信息

绝大多数订单系统里只有一种支付模式，微信支付，支付宝支付等等，我们需要记录回调的信息

|订单ID|支付类型|下单第三方商户号|下单第三方交易流水号|支付金额|
复制代码

商户号记录可能会用到的商户统计问题，比如多个商户号的支付模式，可以记录资金的流向

5，价格信息

商品可能存在的价格：进货价，市场价，销售价，实际支付时的单价，结算价

订单需要保存的：商品总支付金额（不包含运费，所有商品销售价*购买数量），商品总运费，商品总调整金额（即各种插件优惠劵等优惠金额），商品总的需要结算的金额

6，结算信息

在SAAS平台中，通常会需要对售出的商品进行结算，我们需要记录下单时的结算价

订单商品表
|订单ID|商家ID|商品ID|商品名称|商品头图|款式ID|款式名称|款式头图|原价|售卖价|下单价格|购买数量|支付金额|运费金额|结算价|
复制代码

7，售后信息

售后的配置一般都保存在商品的快照里，取实时的话，就是拿商品的售后配置信息

8，优惠信息

参加活动是商品非常常见的需求，各种组合方式，也带来了各种复杂的逻辑设计，但万变不离其宗，都是对于价格的变动，我们定义为计价系统，后续进行叙述。

订单价格调整表
|订单ID|调整类型|调整金额|关联活动ID|关联活动信息|是否参与计价|
复制代码

对于活动和插件的延伸：我们在普通交易的一个订单中，我们往往需要在下单时，就计算出这个订单使用了多少优惠，以及这个订单下单某个商品款式使用了多少优惠，此时我们需要把订单调整金额，也冗余到订单表和订单商品表中，所以最终的表设计为：

订单表
|订单编号|订单状态|下单时间|用户ID|商家ID|商品总金额|运费总金额|优惠总金额|支付金额|支付状态|支付时间|
复制代码

订单商品表
|订单ID|商家ID|商品ID|商品名称|商品头图|款式ID|款式名称|款式头图|原价|售卖价|下单价格|购买数量|支付金额|运费金额|结算价|优惠金额|下单单价|
复制代码

总结

这里我们讨论哪些需要存储，哪些只要关联主键，取决于产品需求本身是要求以下单时的信息为准，还是以实时的配置信息为准。我们在此可以看到，其实订单表可以认为是商家---纬度的信息，订单商品表是商品款式---纬度的信息，所以当具体到商家的一些关于下单的配置时，可以冗余到订单表，比如商家的配置限购优惠之类的，而关于商品的信息，比如分销配置，核销配置，结算配置，售后配置等等跟商品关联的信息，可以在订单商品表考虑进行冗余