一,订单系统的最小模型
|===订单信息============| |=======商品信息====================|======支付信息========|
|订单编号|订单状态|下单时间|用户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|款式名称|款式头图|原价|售卖价|下单价格|购买数量|支付金额|运费金额|结算价|优惠金额|下单单价|
复制代码
总结
这里我们讨论哪些需要存储,哪些只要关联主键,取决于产品需求本身是要求以下单时的信息为准,还是以实时的配置信息为准。我们在此可以看到,其实订单表可以认为是商家---纬度的信息,订单商品表是商品款式---纬度的信息,所以当具体到商家的一些关于下单的配置时,可以冗余到订单表,比如商家的配置限购优惠之类的,而关于商品的信息,比如分销配置,核销配置,结算配置,售后配置等等跟商品关联的信息,可以在订单商品表考虑进行冗余
近期评论