- 创建订单掉败(终态)
- 等待买家付款
- 付款确认中
- 买家付款掉败(终态，依附需求而定)
- 买家付款成功
- 卖家已发货
- 买家已收货
- 退货中
- 退货成功(终态)
- 订单封闭(终态)
结论
综上，我们可以得出放入数据库’订单状况‘字段的标准：核心营业流程，向前单向依附。扩大到其他营业实体是一样的，这里说的’订单状况‘字段实际是指该营业实体对应的数据表的主营业状况字段。我们把结论扩大一下：
如不雅某个action属于营业实体对应的核心营业流程，且该action单向依附于其前向的action，则须要将这个action产生的BizState放入到营业实体对应的数据库表的主状况字段中记录。
OrderState字段记录的BizState营业状况有10种，个中4种是终态，其余状况为中心态。这些状况的流转关系为：
4. 问题二、订单表的‘订单状况’字段的字典值的表示情势?
先列出可选项：应用数字标识、应用多‘位’存储方法标识、运器具有明白营业含义的英文字符串标识;对可选项做一一解释：
b、应用多‘位’存储方法标识——将某种行动是否产生对应的状况对应到一个位上，比如‘是否付款’定义在第一位，‘是否发货’定义在第二位，‘是否收货’定义在第三位，‘是否评论’定义在第四位，则状况‘卖家已收货未评论’可以表示为：0111;而‘等待买家付款’则表示为‘0000’;当然这里的‘位’可能是二进制的也可能是N进制，后面我们具体评论辩论。
c、运器具有明白营业含义的英文字符串标识——该筹划和筹划a类似，不过字典值变为具有明白营业含义的英文付出串，如‘等待买家付款’表示为‘WAIT_BUYER_PAY’;
筹划a是数据库字段字典的惯用方法，简单直不雅，然则有一个坏处在于：当字典值较多时，数据库表的应用者记不住字典的含义，须要反复查找材料确认;有人会说将字典值写到字段的注释里，这个在实践中不是很靠谱，平日表建立后，如不雅字段增长了字典值，平日开辟人员都邑忽视更改字典值;并且在应用对象(如pl/sql)萌芽数据库时，并不会将所有字典置魅展示出来;
通干预干与题一的分析，可亲信筹划b应用多‘位’存储方法会增长复杂度，并没有须要，可以经由过程将‘是否评论’状况自力成一个字段进行表示。
筹划c和筹划a类似，好处在于经由过程字典值直接知道营业含义，坏处在于会给编码和手工萌芽时带来复杂度，平日人们也记不住‘等待买家付款’的英文字典
是‘WAIT_BUYER_PAY’，那么手动写sql萌芽‘等待买家付款’时就犯含混了。
折中之后，我们组合筹划a和筹划c，获得筹划d：别的建立一张字典表，存储：数字情势的字典值、字典英文名称、字典中文简称、字典解释;订单实体表的OrderState字段应用数字作为字典值。
对于筹划d，看到OrderState的数字情势状况时，可以先看看字段注释是否有此字典的定义，如不雅没有就取查下字典表，获得字典值和含义;在编码和手动sql萌芽时也会变得比较轻易，数字的位数毕竟要少些;建立字典表的其他好处还有：字典的解释可以写的很具体，在报表中请求展示字典中文名时，也能直接大年夜数据库联表萌芽获得，而不必额外做一次映射。(有参考：数据库表设计(状况字段))
那么对于字典数量很少的状况字段是否有须要额外新建一张字典表呢?这个根据实际情况推敲，平日可以先不建，如不雅后续有营业场景须要再行创建也不迟。
而对于非营业实体表的体系日记/跑批记录表等的状况，则完全可以应用数字情势的字典，因为平日不会有营业场景应用到这些字典值，并且这些字典值域应当会比较小，所以没有须要为他们创建零丁的字典表。
问题中的‘已退款’由‘退款’行动产生，而‘退款’这个action是订单营业实体的核心营业流程，用户异常关怀，然则这个action存在多个前向依附action(付出、发货、收货等)，所以应当自力到一个字段标识。
综上得出结论：
1)、字典值域较多、变更较多、报表等营业场景会应用到的营业实体表的营业状况字段，应用‘筹划d：新建字典表’的筹划处理;如‘订单营业实体表’中的‘订单状况’字段。
2)、字典值域较少、变更较少、报表等营业场景不会应用到的营业实体表的营业状况字段，应用‘筹划a：应用数字标识字典’的筹划处理;如‘付出宝的付出流水表’的‘付出流水状况’字段。
3)、体系日记/跑批记录表的状况字段，应用‘筹划a：应用数字标识字典’的筹划处理;如‘待收货记录表’的‘跑批状况’字段。
5. 问题三、数据库表的‘状况’字段应用何种类型
列出可选项：number(N)、char(N)、varchar2(N)，个中N是一个长度值。
2)、订单表的‘订单状况’字段对应的字典值若何表示?可选项有：应用数字标识、应用多‘位’存储方法标识、运器具有明白营业含义的英文字符串标识;
这个问题重要须要推敲应用处景、扩大性、机能、存储。
‘状况’字段重要应用在萌芽场景，且平日是‘=’或者‘in’的萌芽，并没有区间类的萌芽，故三者差别不大年夜;
对于机能，参考[原创]在Oracle 10g，Number、Char和Varchar2类型作为主键，萌芽效力分析 char(N)、varchar2(N)机能优于number(N)，故舍弃number(N)。
推敲到扩大性，char(N)、varchar2(N)差不多;
推敲到存储，varchar2加倍占用空间更小，故选择varchar2(N)。
推荐阅读
【沙龙】51CTO诚邀您9月23号和多位技巧大年夜咖一路聊智能CDN的优化之路，抓紧时光哦！ 本年4月，高通全球副总裁、高通创投董事总经理沈劲揭橥文┞仿《低谷中的前沿科技》，激发了业内的诸>>>详细阅读
本文标题：关于数据库“状态”字段设计的思考与实践
地址：http://www.17bianji.com/lsqh/37545.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示