一、背景问题
接到新增业务时,一些程序员总是想着往表里简单的增加字段，能实现功能就可以了,然而却没考虑到系统健壮性。如果你有这个习惯，那就来看看下面的例子吧，我将描述一个产品业务的增量迭代过程，你会看到开发先于设计带来的麻烦。
二、业务描述和前提
| 业务 | 描述 |
|---|---|
| 推荐功能v1.1 | 用户注册时填写推荐人的推荐码，后台cms可以进行统计某个客户经理，用户的推荐量，项目投资的推荐量 |
已建表（只列出业务涉及的字段，其他字段省略）：
三、错误的示范
先来看看懒猿的做法：
呵呵，简单，用户表加个推荐码RefererCode，订单表也加上，后台就可以统计了。
结果，后端的确可以根据推荐码去统计对应推荐人的推荐结果。
若再新增业务：
| 业务 | 描述 |
|---|---|
| 推荐功能v1.2 | 统计所有客户经理，所有用户推荐的数据。 |
此时想做统计，不知道推荐人是客户还是经理,啊脸长了没对客户和经理做区分，好吧，对用户表和订单表再分别新增字段RefererType。嗯，此时自己感觉有点心累了，但还是忍着。
再增新业务:
| 业务 | 描述 |
|---|---|
| 推荐功能v1.3 | 新增融资推荐,推荐用户去申请融资 |
已建表：
继续给项目表添加RefererCode,RefererType字段，很容易呀，后端统计单个用户所有推荐数据时，关联了三个表 -_-|||
SELECT SUM(RCount) FROM(
SELECT COUNT(0)AS RCount FROM User WHERE RefererCode='xxx'
UNION
SELECT COUNT(0)AS RCount FROM Order WHERE RefererCode='xxx'
UNION
SELECT COUNT(0)AS RCount FROM Project WHERE RefererCode='xxx'
)
再给你新增一个业务：推荐码可以更改。意味着RefererCode会变，估计懒猿会大叫一声“What?”.瞬间就想求产品不要再变动业务了。此时你会被产品翻白眼的。
四、再次重新设计
再回到最初需求初版，一开始就画个DFD(数据流图),就能找出合理的数据结构，使得数据表更健壮，也不容易违反数据库三段式。
注册推荐、投资推荐的DFD图dfd1（融资申请模块省略）：
dfd1拆分出两个子数据流图：
最终得到的PDM（物理数据模型）如下图所示。
五、小结
作数据流图，花去不到一个小时。对不进行作图分析设计的模块功能，维护需要一两天，bug重重，扩展极差。磨刀不误砍柴工，养成软件开发过程中的习惯，才能写出高质量代码，谢谢阅览。
1135
