个人数据库设计实践（一）

　　兜兜转转，忽然发现我如今已是一个老司机了，一直写代码都很忙，没有把不少点点滴滴的记录下来，今天开始就开始一个系列，分析当年我接触或者我设计过的表结构，有好有坏，有欢喜也有泪水。不少实践经验来自于踩了一个又一个的坑，从如今的角度去回想，在设计的时候若是那么作，也许我就不须要改代码了……

　　欢迎各位在评论区讨论，我只是想分享一下见解，也许有高人有更好的解法。如下案例从个人实践中简化而来，个别命名或者设计请勿对号入座，字段名等也是随便写的，只做示例。

 

问题：一个流程管理的模块如何设计表结构

需求细节：产品的需求大约是这样，一个订单取消退货的流程，中间有审批环节，全部人都经过之后，能够执行取消动做，全部的退订申请都须要有时间记录。

Round1

开发疑问：

（此处心里暗暗的骂产品经理一千遍，又来搞我，一句话需求。）

数据量多大？不知道

审核动做须要记录什么？审核人，审核时间。

审核人有几个？3个，销售主管，销售总监，财务

 

Round2

产品看了一下，彷佛和他说的差很少，没毛病。转过一圈后问，咱们能够获取到每一个取消订单的耗时吗？妈蛋，二次需求或者说没把需求一次说全。这个时候开发就须要自行帮产品经理脑补。那么

申请退款的发起人不必定是客户，是否是也须要记录？

即便审核完成，最后执行退货动做也须要耗时间，那么退货开始和结束时间其实须要另外的两个字段来记录？

OK，那么把各类时间都给它加上。这个时候设计上没什么难度，难度是谁知道产品经理给你漏了什么关键需求……

 

 

Round3

产品经理退下以后，给销售经理打了个电话，据说大家有一个退货的需求？

是，是，最近不是315嘛，客户要退，那么就必须给退啊，客户是上帝啊。哦对了，咱们这里退货还要分全退和部分退，这个能够支持吗？

什么鬼？那若是部分退，我是否是还要收手续费？

没错啊，财务是这么定的，30天内免费退换货，30天后要按比例收。

妈蛋，我让产品经理和你来细化一下需求。

（此处和产品经理撕逼100遍……）

细致的分析：

退货有类别的区分，退货其实须要按照操做流程，退货内容，审核流程等将表细分，经过一个统一的退货id来关联。

操做流程等的记录建议分离开来，不然之后扩展需求会有隐患。

相关的表设计修改以下图：

cancellation_info:退货信息，算是主表

cancellation_audit:退货审批

cancellation_product:退货产品及明细

(备注：

1. 退货产品及相关信息这里用到了主从表，为何这么用或者也许有其余设计，这里不做展开，由于我实际案例中碰到的就是这样。
2. 也见过把退货产品加一个类别区分后直接放入订单表的设计，这样之后统计算某产品销售总数确实是方便了，和订单分开2张表这样的设计也是能够接受)

 

 

Round4

OK，终于基本搞定销售经理的需求了，那么再给财务打了个电话确认需求。

喂，据说咱们这里有一个退货的需求和您确认一下。

好啊，如今退货审批简化了，我这里不须要审批，只须要执行，销售那边确认完，算好退款金额给我，我只执行退款。

什么？……

（心中默默的哭泣）

疑问点：

流程须要变动吗？变动频率是多少？

审核流程是单向的流程吗？例如取消缘由没写清楚，是执行退回操做，以后同一笔退订申请能够再走审核流程，仍是必须另起一个流程？

分析：

流程变化这种事很难控制，因此流程和时间节点记录不能用横表来扩展，这样的后果就是一旦流程变动，就要变动数据表。

横向的表也不能处理跳回和反复执行的流程。

现今的系统设计时，操做人操做时间等的记录都须要更完善，因此能考虑的都给它考虑上，加上各类note，memo，记录各类异常状况或者备注以防万一。

新的audit表再也不是按cancellationid对应一条记录，而是一个cancellationid对应多条记录，并有了独立的auditid。并且每一步审核人均可以独立的记录result和memo，记录会更详尽，各个审核时间也有了一个统一的字段，以后统计某一个退货审核的耗时，能够用cancellationid来检索，最大最小时间相减便可。另外，我我的的建议是将退货的发起时间和执行完成时间也记录在此。

 

Others

实际案例中，还有不少不少的细节，如财务须要记录凭证和其余事物。销售那里还有退货地址等等

销售那里9成会提说有一个当前的退货状态的实时报表，因此在cancellation_info里加个状态标志位等，方便实际应用我以为也是能够考虑的设计。

 

总结

我以为数据表设计2个主要思辨方向：一个是业务驱动，一个是统计驱动。

业务驱动是说，业务需求须要你把各类数据记录下来，没有记录之后就作不了相关的功能，而后咱们按照各类数据库设计的模式记录数据。统计驱动是说知足了基本业务流程须要后，不少数据的实际应用主要是各类统计报表中，要考虑到统计报表时获取数据的方便性。在设计时，兼顾考虑2方面的需求，这个案例主要说的是业务相关的驱动，要统计审核时间等又与统计驱动有关。

设计多个表其实对于开发来讲没有什么难度，难度在于业务经验，预知可能的变化点，提早作好规划。一个好的产品经理若是能及早的想到这些点，那么开发就能够少走不少的弯路。若是产品经理帮不了忙，那么只有靠本身，多和各个实际业务打打交道。

流程记录，步骤记录，时间点记录，建议用不要用横向设计。