在进行数据库设计时，我们经常会遇到各种各样的业务需求，从而设计出各种各样的表。而想要做好一个数据库，不但需要前期对各种业务需求的深度理解，还需要在后期项目完善的过程中对数据库更新修改从而使得数据库设计的越发完美。
  对于那些涉及到业务的表或许不太好入手，但项目中经常出现的各种字典表就很好入手了。项目越大那么字典表就少不了，字典表就是常见的类型、状态、单位之类特定的一些值。有些人每一个业务或模块都设计一个字典表用来标识类型或状态等等，这样表的数量就不少了。其实我们可以将一些字典表合并起来，用两个表就能实现多个表的功能。下面我以三个状态表来演示。
  下面是三张表的内容，表名分别是Order_Status、Clip_Status、RedPacket_Status

  上面三张表的作用分别是：第一张用来处理订单的状态信息，第二张用来处理卡（比如会员卡）的状态信息，第三张用来处理红包的状态信息。根据上面的情况可以明显的看出，第三张表是多余的，完全可以去掉第三张表而利用第二张表的数据也没问题，但是因为业务需要给第三张表的加上其他的状态时，岂不是又要加上这张表，如果加在第二张表呢？也是不行的，如果需要对每个业务模块的字典表进行维护，那第二张表岂不是有两个业务模块与之对应，那样就显得有点不伦不类了。
  接下来的这种方法合并的方法就显得更加的灵活转变了。我们可以把每个业务模块假设成一个大类，而业务模块用到的字典表数据就假设成小类。按这个思路就能把多个字典表完成合并了。
  下图为表结构：

表数据：
连表查询结果：

有人会说那个卡状态和红包状态不还是有两种一样的值吗？这样还是不够好啊。很简单，在Functional_Describe表中给一样的值加上一个公共区就行了。见下图：

总结：很明显这就是一对多的关系，一个业务或模块对应多个状态或类型，这样设计可以省略多个表，扩展性也可以，对于新加入的业务，只需要先在Functional_Describe表中添加它的描述，在去Status表中添加与它对应的字典表数据就行了。只涉及数据的录入而不需要去添加表。