作家
登录

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

作者: 来源: 2017-09-20 14:54:34 阅读 我要评论

【沙龙】51CTO诚邀您9月23号和多位技巧大年夜咖一路聊智能CDN的优化之路,抓紧时光哦!


1. 问题综述

没有营业意义的SubState组合被舍弃。表中的标黑单位格,表示这个BizState是毫无意义的,因为‘未下单’的订单对于我们来讲是不存在的,这类组合须要舍弃;同样的,还有很多其他的组合也是不存在的,被舍弃掉落,未展示在上表中,如‘已下单已付款未发货已收货’这种。

2. 营业分析

3. 问题一、订单表的‘订单状况’字段应当包含哪些状况值?

4. 问题二、订单表的‘订单状况’字段的字典值的表示情势?

5. 问题三、数据库表的‘状况’字段应用何种类型

6. 问题结论汇总

7. 参考材料

正文

比来在做订单及付出相干的体系,在订单表的设计阶段,团队成员就“订单状况”数据库字段设计有了一些不合,网上也有不少关于这方面的思虑和商量,结合这些材料和项目标实际情况,拟对一些共性问题进行更深一层的思虑,笔耕在此,和大年夜家一路商量。

1. 问题综述

这里的不合点即竽暌剐团队内部的不合点,也有收集上常见的一些不合点,先将存在的不合点抛出来:

1)、订单表的‘订单状况’字段对应的字典值应当包含哪些状况值?对于‘已评论’、‘已退货’、’已退款’这类状况是放到‘订单状况’中?照样自力一个字段标识?

3)、订单表的‘订单状况’字段应用何种类型?可选项有:number(N)、char(N)、varchar2(N);

2. 营业分析

我们先不去看问题,先来看看和‘订单(Order)’实体相干的营业是如何的。下面我们会针对可能改变订单实体状况的行动已经状况变更的可能性进行具体的分析。

订单营业实体相干的营业流程如下:下单(create)--> 买家付款(pay)--> 卖家发货(deliver)-->买家收货(receive)-->退货(rereturn);此外,还有退款(refund)和评论(comment),这两个行动比较特别,其前向行动可能存在多个。

起首,可以改变订单营业状况【这里的状况不是指‘订单状况’(OrderState)这个数据库字段,而是指实际营业状况,我们简记为(BizState),以和OrderState区分开】的行动有哪些?按照典范电商的营业流程,重要的行动(action)有:下单、付款、发货、收货、退款/退货、评论;每一种行动的产生,都邑导致订单的营业状况BizState产生变更,比如‘下单’行动会创建订单,‘付款’行动会使订单变为‘已付款’,‘发货’行动可以使订单状况变为‘已发货’,‘收货’行动会使订单状况变为‘已收货’,‘评论’行动会使订单状况变为‘已评论’。‘退款/退货’action不是所有订单都支撑的,为减小复杂度,暂不推敲它们。

其次,细分下每种action对BizState带来的影响,会发明还可以细分为四种子状况(subState):action未开端(标记为0)、action进行中(标记为1)、action成功(标记为2)、action掉败(标记为3);理论上,将所有action的所有subState进行分列获得4*4*4*4*4=1024(暂未推敲‘退货’);实际上,很多组合是没有营业意义的,是弗成能存在的,比如‘未开端已付款...’(***20)这一类组合是弗成能产生的,应当舍弃。用表格将上述的组合分析如下:

目次

经由过程上表,我们可以发明些的规律:

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

综合下来,我们获得上表的BizState,留意这里的Comment action未进行细化处理,如不雅细化处理,会发明BizState的可能性会增大年夜很多很多。

接下来我们就之前提出的┞封些问题进行逐个评论辩论。

3. 问题一、订单表的‘订单状况’字段应当包含哪些状况值?

如不雅嫌分析过程过于烦琐,可以直接拉到最后看结论。

什么样的‘订单营业状况’(BizState)须要记录到体系层面的‘订单状况’(OrderState)字段呢?如不雅记录多了,则体系处理的复杂度会增大年夜;记录少了,那么‘订单状况’(OrderState)字段就不克不及完全的表示出订单实体状况变更情况。

核心状况

经由过程膳绫擎的营业分析可亲信大年夜部分存在依附关系的action(create、pay、deliver、receive),他们产生的合理的SubState组合是异常少的,并且他们之间的依附是单向依附,状况机的处理也很简单,是以,我们先将这部分BizState纳入到OrderState中:

  • 等待买家付款
  • 买家付款成功
  • 卖家已发货
  • 买家已收货

今朝的订单状况流转:

‘action行动’掉败的情况

对于‘付出’掉败,则要看需求,如不雅需求请求用户可以持续付出,则订单须要保存,并且状况仍然为‘等待买家付款’,如不雅不许可再付出,则理论上可以将BizState置为‘付出掉败’终态,所以,‘付出掉败’的BizState终态也应当记录到OrderState字段中。

对于‘发货’掉败、‘收货’掉败的情况,平日是不会产生的,即使产生也不属于体系可以或许控制典范畴,体系记录并无意义,更具扶植性的做法是经由过程线下手段尽快解决问题,从新发货等等,所以对于这些状况体系的OrderState字段不予记录。

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

  推荐阅读

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

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


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

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

关键词: 探索发现

乐购科技部分新闻及文章转载自互联网,供读者交流和学习,若有涉及作者版权等问题请及时与我们联系,以便更正、删除或按规定办理。感谢所有提供资讯的网站,欢迎各类媒体与乐购科技进行文章共享合作。

网友点评
自媒体专栏

评论

热度

精彩导读
栏目ID=71的表不存在(操作类型=0)