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

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

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

需求细节：产品的需求大约是这样，一个订单取消退货的流程，中间有审批环节，所有人都通过以后，可以执行取消动作，所有的退订申请都需要有时间记录。

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方面的需求，这个案例主要说的是业务相关的驱动，要统计审核时间等又与统计驱动有关。

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

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

我的数据库设计实践（一）