95992828九五至尊2

简简单单财务功用的设计思路0322,字段设计的想想与执行

一月 26th, 2019  |  882828九五至尊手机版

若是你要为一个出纳员事务所设计软件,那么本文内容显明属于幼儿园水平。不过只要你只是在一个小软件中加一点财务效能,那么本文可以提供一些思路。假诺大家必要支出一个托儿所学生管理连串,其中有个子项效用是收费管理。

第一我们要统筹两张记录表,分别记录消费行为和支付行为。这里要求强调的是消费行为和支出行为万万不可设计成1:1的关联,最少应该是N:1的关系,因为现实生活中,学生家长完全可以四遍性开发两个多个消费行为。比如说超过一半老人家按月缴纳学习开支,不过有些老人喜欢拖欠,每七个月缴纳五回,每一次缴纳八个月学习费用。

目录

说不上我们要规划一张消费凭证实体表,记录发票或者收据的新闻。那里须求强调的是开支凭证不要和消费行为强关联,应该和支出行为强关联,两者应该是1:N的涉及。一个开支凭证可以覆盖多少个开发行为。

  1. 题目汇总

  2. 事务分析

  3. 题目一、订单表的‘订单状态’字段应当包罗怎么样情状值?

  4. 问题二、订单表的‘订单状态’字段的字典值的代表方式?

  5. 问题三、数据库表的‘状态’字段使用何连串型

  6. 问题结论汇总

  7. 参考资料

882828九五至尊手机版,此地讲一下记录表和实体表的不相同,实体表每条记下代表某个东西,比如说一个人,一辆车,一个商行。记录表每条记下代表了一件工作,比如说吃了一顿饭,请了五次假。

正文

末尾就是计费规则表,对于只帮忙手工收费的软件系统,计费规则只是辅助系统,协理财务人员在收费时算一下总和,它不有所强制性。按照用户的急需,计费规则可以相比较简单,比如说每人每月收费完全相同,雷打不动都是1000元(不足一个月仍旧收1000元)。计费规则也足以极度复杂,比如说依据分裂学生的历史消费状态提交分裂折扣,在本幼儿园缴纳学习成本当先20000元的父二姨打九折,在本幼儿园缴纳学习话费超过50000元的养父母打八折等等。

日前在做订单及支付相关的种类,在订单表的设计阶段,团队成员就“订单状态”数据库字段设计有了一部分抵触,网上也有千千万万关于那方面的合计和切磋,结合这么些资料和类其余实际上境况,拟对有些共性问题开展更深一层的构思,笔耕在此,和豪门一起探讨。

1. 问题归咎

此间的分化点即有团队内部的不一样点,也有网络上常见的有的差异点,先将设有的差异点抛出来:

1)、订单表的‘订单状态’字段对应的字典值应当包罗怎么样情形值?对于‘已评论’、‘已退货’、’已退款’那类状态是放到‘订单状态’中?仍然单独一个字段标识?

2)、订单表的‘订单状态’字段对应的字典值如何表示?可选项有:使用数字标识、使用多‘位’存储方式标识、使用所有强烈工作含义的英文字符串标识;

3)、订单表的‘订单状态’字段使用何连串型?可选项有:number(N)、char(N)、varchar2(N);

倘使嫌分析进度过于啰嗦,可以一直拉到最后看结论。

2. 事务分析

大家先不去看题目,先来看望和‘订单(Order)’实体相关的工作是什么样的。下边大家会指向可能更改订单实体状态的表现已经状态变化的可能性进行详细的辨析。

订单业务实体相关的业务流程如下:下单(create)–> 买家付款(pay)–>
卖家发货(deliver)–>买家收货(receive)–>退货(rereturn);其余,还有退款(refund)和评论(comment),那三个表现比较新鲜,其前向行为或许存在多少个。

882828九五至尊手机版 1

第一,可以改变订单业务意况【那里的气象不是指‘订单状态’(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)这一类组合是不能暴发的,应当放弃。用表格将上述的组合分析如下:

882828九五至尊手机版 2

由此上表,大家得以窥见些的规律:

‘下单’、‘付款’、‘发货’、‘收货’前四种action是存在依靠关系的,亦即后一个action依赖于前一个action的成就;所以,他们的SubState组合意况就会相当少;

‘评论comment’那么些action的SubState和其他情状组合会有很多种可能;除了前方了两行是‘X’,后面是‘?’或者‘Y’,‘?’是指须求上是不是同意在相应的BizState上拓展评论,尽管同意,则每种BizState需求多出4种可能,那样组合的可能性就会变得很大。

从未有过工作意义的SubState组合被废弃。表中的标黑单元格,表示这一个BizState是毫无意义的,因为‘未下单’的订单对于大家来讲是不设有的,那类组合要求屏弃;同样的,还有许多别样的结合也是不设有的,被舍弃掉,未出示在上表中,如‘已下单已给付未发货已收货’那种。

一般说来某个action的SubState为‘1拓展中’、‘3败诉’时,会被忽略,但也有不相同;比如‘付款’action的‘3惜败’状态,和‘付款’action的‘1展开中’状态,具体分析见后边内容。

大意所有action的‘0未开头’SubState状态。因为那类SubState对于BizState不会带来变化。

概括下来,大家赢得上表的BizState,注意那里的Comment
action未举办细化处理,假使细化处理,会意识BizState的可能会附加很多广大。

接下去大家就以前提议的这一个题材开展逐个商量。

3. 题材一、订单表的‘订单状态’字段应当涵盖怎样处境值?

什么的‘订单业务情形’(BizState)需求记录到系统层面的‘订单状态’(OrderState)字段呢?即便记录多了,则系统处理的复杂度会叠加;记录少了,那么‘订单状态’(OrderState)字段就不可能完整的意味出订单实体状态变化情状。

基本状态

由此地点的业务分析可见:一大半设有依靠关系的action(create、pay、deliver、receive),他们暴发的合理性的SubState组合是极度少的,而且她们之间的重视性是单向依靠,状态机的拍卖也很简单,因而,我们先将那部分BizState纳入到OrderState中:

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

近日的订单状态流转:

882828九五至尊手机版 3

‘action行为’败北的景色

对于action的SubState是‘3破产’的处理,须要针对差距的action进行剖析。类似‘下单Create’那样的action,即使失败,则可以直接将OrderState置为‘订单创制败北’,因为Create
action是率先个action,它的挫败意味着Order实体出生即死,BizState置为终态,对于那几个BizState应当纳入到OrderState中著录,不过这几个OrderState其实对于用户并无多大用处,因为用户并不会关心下单战败的订单,他更尊敬的是再度下单;

对此‘支付’失利,则要看必要,如若急需需要用户可以持续支付,则订单要求保留,并且状态照旧为‘等待买家付款’,假设分裂意再开发,则辩解上可以将BizState置为‘支付败北’终态,所以,‘支付失利’的BizState终态也应有记录到OrderState字段中。

对此‘发货’失利、‘收货’战败的情景,常常是不会爆发的,即使暴发也不属于系统可以决定的局面,系统记录并无意义,更具建设性的做法是透过线入手段尽快解决问题,重新发货等等,所以对于那么些景况系统的OrderState字段不予记录。

这般下来大家的OrderState字典值增添到6个,加粗项为新增:

  • 创建订单失利(终态)
  • 等候买家付款
  • 购买者付款失利(终态,看重需要而定)
  • 买家付款成功
  • 卖方已发货
  • 购买者已收货

眼前的订单状态流转:

882828九五至尊手机版 4

‘action行为’举办中的情形

对于action的SubState是‘1开展中’的处理,同样须要实际境况具体分析。‘付款’行为是用户发起的,可是并不是和订单系统之间的并行,涉及到支付连串的处理,那几个小圈子也不是订单系统可控的,但提到到钱,用户比较关系,所以对于那样一个中间态,大家需求记录,以便用户通过订单系统查询订单状态,为便于用户精晓,将此景况在OrderState中记为‘付款确认中’;‘发货’‘收货’进行中的情形,不是订单系统可以操纵的圈子,大家得以把她们公开行为‘未初阶’处理,比如‘发货进行中’,订单系统的OrderState值为‘买家已给付’,但给用户观察的提醒新闻是‘买家已给付,等待卖家发货’,实际上那时候卖家可能正在发货中,不过用户不会去关注到底有没有打包好货物什么的,所以这类‘举办中’状态可以废弃。那样下来订单系统的OrderState字段又多了一个字典值:‘付款确认中’:

  • 开创订单败北(终态)
  • 等待买家付款
  • 付款确认中
  • 购买者付款失败(终态,依赖须要而定)
  • 购买者付款成功
  • 卖家已发货
  • 买家已收货

现阶段的订单状态流转:

882828九五至尊手机版 5

‘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有多了三种字典值,那里大家不考虑一个订单中有多种商品的意况,故把‘退货成功’当着终态处理,如果是一个订单多种货物的情景,要求重新仔细分析。加粗项为新增:

  • 始建订单败北(终态)
  • 等待买家付款
  • 付款确认中
  • 买家付款失利(终态,依赖需求而定)
  • 买家付款成功
  • 卖方已发货
  • 购买者已收货
  • 退货中
  • 退货成功(终态)

现阶段的订单状态流转:

882828九五至尊手机版 6

‘退款refund’的处理

最终来看下‘退款refund’行为对应的BizState的拍卖。首先,大家需求了然‘退货’和‘退款’是三种差别的事体表现,他们的涉及是:平时意义上,‘退货’必然造成‘退款’,可是‘退款’可以没有‘退货’的涉企(那里不琢磨万分情状,比如对于虚拟商品来讲,付款成功一般认为着收货成功,那时候就不得不是在由‘退货’导致‘退款’),比如电商允许用户付款成功后接过货物前发起‘退款’。也就是说‘退款refund’并不单向依靠于‘退货rereturn’,和‘评论comment’一样是多项依赖,所以,大家得以参照‘评论comment’的处理方式,单独建立一个字段‘RefundState退款状态’记录‘退款refund’发生的BizState,这几个情景字段的字典值有:退款中,退款成功。

其余景况考虑

其它,可能还有一部分增强型须求,让客户体验更好,比如用户可以创制订单之后付款在此之前,将订单裁撤,或者由系统跑批将用户长日子未支付的订单关闭,那会发出一种新的action——‘close关闭’,对应的会生出一种新的有意义的BizState——‘订单关闭/取消’,那么些不属于要旨流程中的,且并无纠结之处,不予详细探究,罗列如下:

  • 开创订单失利(终态)
  • 等候买家付款
  • 付款确认中
  • 买家付款战败(终态,倚重须要而定)
  • 买家付款成功
  • 卖方已发货
  • 购买者已收货
  • 退货中
  • 退货成功(终态)
  • 订单关闭(终态)

结论

综上,大家得以汲取放入数据库’订单状态‘字段的规范:主旨业务流程,向前单向依靠。扩张到此外业务实体是同等的,那里说的’订单状态‘字段实际是指该工作实体对应的数据表的主业务状态字段。大家把结论增添一下:

假使某个action属于工作实体对应的着力业务流程,且该action单向依靠于其前向的action,则要求将以此action爆发的BizState放入到工作实体对应的数据库表的主状态字段中著录。

OrderState字段记录的BizState业务意况有10种,其中4种是终态,其他情状为中间态。那个情状的漂泊关系为:

882828九五至尊手机版 7

4. 题目二、订单表的‘订单状态’字段的字典值的表示格局?

先列出可挑选:使用数字标识、使用多‘位’存储形式标识、使用所有强烈作业含义的英文字符串标识;对可选项做逐一分解:

a、使用数字标识——使用一个数字标识一种情形,并未须求是sequence的;如‘等待买家付款’表示为‘0’;

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查询时也会变得比较易于,数字的位数毕竟要少些;建立字典表的其余利益还有:字典的演讲可以写的很详细,在表格中需求出示字典汉语名时,也能间接从数据库联表查询得到,而不必额外做几次映射。(有参考:数据库表设计(状态字段))

那就是说对于字典数量很少的情景字段是或不是有要求额外新建一张字典表呢?这些根据实际意况考虑,寻常可以先不建,假使后续有事情场景需要再行成立也不迟。

而对此非业务实体表的系统日志/跑批记录表等的事态,则完全能够利用数字方式的字典,因为一般而言不会有工作场景使用到这个字典值,而且这么些字典值域应当会比较小,所以并未要求为他们创建单独的字典表。

综上得出结论:

1)、字典值域较多、变化较多、报表等工作场景会使用到的业务实体表的事务景况字段,使用‘方案d:新建字典表’的方案处理;如‘订单业务实体表’中的‘订单状态’字段。

2)、字典值域较少、变化较少、报表等事情场景不会选用到的事体实体表的事体意况字段,使用‘方案a:使用数字标识字典’的方案处理;如‘支付宝的支付流水表’的‘支付流水状态’字段。

3)、系统日志/跑批记录表的景况字段,使用‘方案a:使用数字标识字典’的方案处理;如‘待收货记录表’的‘跑批状态’字段。

5. 题目三、数据库表的‘状态’字段使用何种类型

列出可挑选:number(N)、char(N)、varchar2(N),其中N是一个长度值。

这么些题材至关首要须要考虑选拔意况、伸张性、性能、存储。

‘状态’字段重点选取在询问现象,且一般是‘=’或者‘in’的询问,并不曾区间类的询问,故三者差距不大;

对于性能,参考[原创]在Oracle
10g,Number、Char和Varchar2类型作为主键,查询功能分析
char(N)、varchar2(N)性能优越number(N),故废弃number(N)。

考虑到扩充性,char(N)、varchar2(N)几乎;

设想到存储,varchar2尤其占有空间更小,故接纳varchar2(N)。

综上:选用varchar2(N)作为数据库‘状态’字段的连串。

6. 问题结论汇总

1)、订单表的‘订单状态’字段对应的字典值应当涵盖哪些意况值?对于‘已评论’、‘已退货’那类状态是放到‘订单状态’中?依然独立一个字段标识?

设若某个action(行为,如开发)属于工作实体对应的主题业务流程,且该action单向依靠于其前向的action,则须要将这些action发生的政工情况放入到工作实体对应的数量库表的主状态字段中记录。

问题中的‘已评论’由‘评论’行为时有暴发,而‘评论’那几个action并不是订单业务实体的主干业务流程,且可能存在多个前向信赖action(支付、发货、收货等),所以应当独立到一个字段标识。

题材中的‘已退货’由‘退货’行为暴发,而‘退货’这么些action是订单业务实体的主干业务流程,用户格外关切,且只单向依靠于‘收货’action,所以应当记录到订单业务实体表的‘订单状态’字段中。

题材中的‘已退款’由‘退款’行为发出,而‘退款’那个action是订单业务实体的大旨业务流程,用户非凡关心,不过那么些action存在七个前向看重action(支付、发货、收货等),所以应该独立到一个字段标识。

2)、订单表的‘订单状态’字段对应的字典值怎么样表示?可选项有:使用数字标识、使用多‘位’存储情势标识、使用具有明显工作含义的英文字符串标识;

i、字典值域较多、变化较多、报表等事情场景会使用到的作业实体表的业务情形字段,使用‘方案d:新建字典表’的方案处理;如‘订单业务实体表’中的‘订单状态’字段。

j、字典值域较少、变化较少、报表等作业场景不会利用到的政工实体表的政工情状字段,使用‘方案a:使用数字标识字典’的方案处理;如‘支付宝的付出流水表’的‘支付流水状态’字段。

k、系统日志/跑批记录表的处境字段,使用‘方案a:使用数字标识字典’的方案处理;如‘待收货记录表’的‘跑批状态’字段。

3)、订单表的‘订单状态’字段使用何连串型?可选项有:number(N)、char(N)、varchar2(N);

varchar2(N)占用存储更少,且所有同等的习性、伸张性,采纳varchar2(N)作为数据库‘状态’字段的门类。

7. 参考资料

多少库表设计(状态字段)

[原创]在Oracle 10g,Number、Char和Varchar2类型作为主键,查询功用分析

【编辑推荐】

相关文章

Your Comments

近期评论

    功能


    网站地图xml地图