软件开发中的实用小技巧（解决复杂问题的银弹）

先说结论，增量扩容法解决业务研发中的需求问题，特别是控制逻辑。

经常听到一句话就是，增加一层能解决代很多代码耦合问题，如果不能再增加一层。我想说数据库架构的业务系统里，增加一个栏位常常也能带来同样的效果。这里分享两个case。

case 1：

先看页面：

这样的数据分别存在两张表里，一张主表和一张子表（保存扩展数据，且经常变动的）
以bsc_combined_info 这张表表示一个人的绩效bsc概要信息，处于节省考虑，而且annual数据不经常变动，所以放到了一起（为了保存年度目标这样的大json，使用了mysql的json类型这样的特定字段，非常合适的，可能查询有点慢），而是季度数据就单独放到一张表bsc_quarter，满足特定的维护信息, 尽量减少对主表的影响，通过设置外键关联主表，这样一切都很好。但是有一个需求，状态维护，年度数据有状态，季度数据有状态，第一个版本就是通过在主表设置一个字段，即代表年度目标数据的状态，又代表季度数据的状态，这样会导致季度目标变化时候需要覆盖掉主表里的唯一的status，那样的当需要同时展示两种数据的状态的话（在年度填报快要结束和Q1开始填报这样的特殊时期，年度数据和季度数据都会别列出来，就会出现数据问题，因为检索的时候需要根据状态来筛选，比如查看待提交（0表示），（3表示已提交），可能是年度数据已经审批（8表示）了，但是季度还是0表示的待提交，这样导致找出来了bscInfo的status全乱了，因为操作季度的时候覆盖掉了年度的status了。这个时候，最高效的办法在主表里增加一个status，比如quarter_status，隔离两个状态，带来的负面影响就是，在查询的时候，需要对两个status进行区别对待，比如1表示已经审批完成，如果按照状态来查询bsc_combined_info表，sql语句需要这样写，如果annual_status等于1的时候，看quarter_status， 如果annual_status不等于1的时候，annual_status 和quarter_status状态都要看，比如查询已经提交的（3表示），这样才能找出来年度目标和季度目标里都是已提交的数据，否则会漏掉数据。 从这个故事里可以看出来，软件系统的复杂度不会消失，只是从一个地方转移到了另外一个地方，这里增加一个字段，分离两个数据的状态，在操作不同数据的时候设置各自的状态，但是却导致了查询的复杂。

case 2：

页面如上

数据权限问题，这是一个特别复杂且难以解释的需求，系统里有二级审批，有普通员工，一般经理和高级经理，还有很多部门。普通员工的bsc审批需要经过一般经理的初审和高级经理的二次审批。而一般经理的bsc需要经过高级经理的初审和老板的二次审批。 系统里有一个列表筛选功能，高级经理如果选择初审状态数据（9表示它的状态），按照一般的基于角色控制的数据权限，会列出来她部门以及子部门的所有状态9的数据，包括普通员工的，但是现在他们提出来一个需求，高级经理只看一般经理的状态9的数据，而普通员工的，他不想看到。而在待二审的列表栏里列出来需要他二次审批的数据。
这个时候，一般经理和普通员工的status都是一样的，比如9表示，这个时候就需要来一个扩容大法了，1. 把普通员工和一般经理的初审状态的数据用两套状态码表示，比如9表示员工的待初审，而一般经理选择19表示，一般员工的已提交状态用3表示，而一般经理的已提交状态用13表示，以此类推。 还有一个办法就是增加一个字段，approval_level，本质也是扩容，普通员工设置成1，而经理设置成2，这样在高级经理筛选数据的时候，根据需要来，他想看什么级别都可以，以此满足需求。副作用，在保存数据的时候，需要根据当前角色设置他们各自的approval_level，带来维护成本增加。

总结：扩容大法好，但是也会增加维护成本。