系统设计——关于数据库表设计的感悟

前一段时间在忙一个MIS系统（不知道MIS系统的百度），系统的目标是可以把数据根据业务的需要录入到不同的库内，比如，A业务的数据要录入到A专属的业务库，B业务的数据要录入到B专属的业务库，同时，系统本身还有一个自己的系统库。这些数据可以来回切换数据源吗？可以。我们的系统服务器是用的tomcat，在server.xml下设置多个数据源，在项目的web.xml中把这些数据源都引用进来，然后在业务逻辑处理的时候切换到指定的数据源就好。记住，用完要切换回系统数据库。
在这样的系统要求下，如果不好好的设计系统的数据库表，坑很多（现在就在填坑），后期由于表设计不好，逻辑复杂了一倍不止，而且由于表的大体结构不能修改，所以还要加一些ETL才能满足业务数据和系统数据的分离。
根据这段经历，我总结了两条感悟：
**1.配置项数据和流程数据要分离。
2.业务数据和系统数据要分离（不分离则选择冗余）。**
关于第一点我来解释一下。配置项数据是什么？比如一个工作流，工作流本身的数据是流程数据，有几个步骤，怎么流向，等等这些都是固定死的。但是工作流上的数据就是所谓的配置项数据，比如，第一个步骤都有那些人，这些人的手机号码是什么，这个步骤对应的操作任务是什么，等等这些都是配置项数据。这些配置项数据都是可以灵活更换的，因为业务有需要随时更换流程上的人，总不能说人家这个人离职走了，还不能更换一个人上去吧，不然业务就无法完成了。这两类数据一定要分离，不要揉合成一张表（犯前人的错误后面坑很多）。现在暂且不说分离的好处，先表表不分离的坑吧。还是拿那个工作流来说。
1.更换一个处理人需要删除一个工作流。
2.删除一个工作流会把所有配置项信息全部删除。无法保存历史信息。
这些坑是一个接一个，都是由于表设计不够好导致的，当事人刚设计好系统表就离职了，挖了一个大坑给我们填，吃一节长一智吧。
关于第二点，其实不是很好处理，有些数据可以是业务数据也可以是系统数据，因为这些数据两边都会用到，很难界定它是系统数据还是业务数据。但是有些很明显的就是业务数据的那就得把它放到业务库内，不要和系统数据放到一块，不然有坑（后期要用ETL导数据到业务库）。
记下这些给自己也给看这文章的你一些启发。