关于数据库“状态”字段设计的思考与实践

如许下来我们的OrderState字典值袈漩加到6个，加粗项为新增：

创建订单掉败(终态)
等待买家付款
买家付款掉败(终态，依附需求而定)
买家付款成功
卖家已发货
买家已收货

今朝的订单状况流转：

平日某个action的SubState为‘1进行中’、‘3掉败’时，会被忽视，但也有例外;比如‘付款’action的‘3掉败’状况，和‘付款’action的‘1进行中’状况，具体分析见后面内容。

‘action行动’进行中的情况

今朝的订单状况流转：

对于action的SubState是‘3掉败’的处理，须要针对不合的action进行分析。类似‘下单Create’如许的action，如不雅掉败，则可以直接将OrderState置为‘订单创建掉败’，因为Create action是第一个action，它的掉败意味着Order实体出身即逝世，BizState置为终态，对于这个BizState应当纳入到OrderState中记录，不过这个OrderState其实对于用户并无多大年夜用处，因为用户并不会关怀下单掉败的订单，他更关怀的是从新下单;

‘action行动’未开端的情况

忽视所有action的‘0未开端’SubState状况。因为这类SubState对于BizState不会带来变更。

‘评论comment’的处理

最后，再来看看‘评论comment’这个action。如不雅需求上请求：只有买家收货后才能提议‘评论’操作，则可以义务‘评论comment’单向依附于‘receive收货’行动，那么可以将这个action的subState对应的少量BizState(应当只有‘买家已评论’、‘卖家已评论’状况)纳入OrderState字段同一记录;然则如不雅需求是：买家鄙人单后就可以开端评论，比如如不雅卖家发货慢了，买家可以上去吐槽，那么‘评论comment’就不是单向依附于‘receive收货’行动了，而是多向依附于‘pay付款’、‘deliver发货’、‘receive收货’，那么这些actions的subState组合可能性就暴增，BizState的字典取值也会暴增，显然，不应当将这么多的BizState交给OrderState来记录，而应当由一个自力的数据库字段负责记录‘评论comment’的SubState，我们可以将这个字段取名

为‘CommentState’(评论状况)，它的字典值不多，只有：‘未评论’、‘买家已评论’、‘卖家已评论’;其实，对于前一种需求，也可以不讲‘评论comment’对应的SubState产生的BizState纳入OrderState，因为用户对于评论与否其实并不是那么关怀的，也就是说‘评论comment’并不是核心营业流程，为了降低核心营业流程的体系处理复杂度，将其大年夜核心营业流程中剥离出来较好。

综上，我们应当将‘评论comment’对应的BizState自力到一个字段中记录。

‘退货rereturn’的处理

再来看看‘退货rereturn’行动对应的BizState的处理。‘退货rereturn’并不是所有订单都邑经历的，然则一旦涉及，则‘退货rereturn’安营业流程上必定是单向依附于单向依附于‘receive收货’，所以应当将‘退货rereturn’产生的BizState(‘退货中’、‘退货成功’，‘退款掉败’和‘未退货’被忽视，见膳绫擎解释)纳入OrderState一并记录;如许我们的OrderState有多了两种字典值，这里我们不推敲一个订单中有多种商品的情况，故把‘退货成功'当着终态处理，如不雅是一个订零丁种货色的情况，须要从新细心分析。加粗项为新增：

创建订单掉败(终态)
等待买家付款
付款确认中
买家付款掉败(终态，依附需求而定)
买家付款成功
卖家已发货
买家已收货
退货中
退货成功(终态)

今朝的订单状况流转：

‘退款refund’的处理

最后来看下‘退款refund’行动对应的BizState的处理。起首，我们须要知道‘退货’和‘退款’是两种不合的营业行动，他们的关系是：通平平易近义上，‘退货’必定导致‘退款’，然则‘退款’可以没有‘退货’的介入(这里不评论辩论间谍作况，比如对于虚拟货色来讲，付款成功平日认为着收货成功，这时刻就只能是在由‘退货’导致‘退款’)，比如电商许可用户付款成功后收到货色前提议‘退款’。也就是说‘退款refund’并不单向依附于‘退货rereturn’，和‘评论comment’一样是多项依附，所以，我们可以参考‘评论comment’的处理方法，零丁建立一个字段‘RefundState退款状况’记录‘退款refund’产生的BizState，这个状况字段的字典值有：退款中，退款成功。

其他情况推敲

别的，可能还有一些加强泻孟耋，让客户体验更好，比如用户可以创建订单之后付款之前，将订单撤消，或者由体系跑批将用户长时光未付出的订单封闭，这会产生一种新的action——‘close封闭’，对应的会产生一种新的有意义的BizState——‘订单封闭/撤消’，这个不属于核心流程中的，且并无纠结之处，不予具体评论辩论，列举如下：

2/4 首页上一页 1 2 3 4 下一页尾页

　　推荐阅读

　　机器人陷入期待值低谷？问题出在哪里

【沙龙】51CTO诚邀您9月23号和多位技巧大年夜咖一路聊智能CDN的优化之路，抓紧时光哦！本年4月，高通全球副总裁、高通创投董事总经理沈劲揭橥文┞仿《低谷中的前沿科技》，激发了业内的诸>>>详细阅读

本文标题：关于数据库“状态”字段设计的思考与实践

地址：http://www.17bianji.com/lsqh/37545.html

1/2 1