ERP数据库表设计有感

        从事IT业10年了，从一个门外汉变成一个“老菜鸟”，见过了一些号称几千万的软件项目，只觉得其中有些软件设计的技术含量都是学生毕业设计级的，不由得想起以前老师在历史课上讲“洋务运动”无法挽救清朝这一说法。永远是好的体制带来好的管理，好的管理带来好的技术，反过来，好的技术不能带来好的管理，更不可能给企业带来起死回生的效果。
        好了，扯远了，不讲这些深刻的大道理，只说说ERP软件设计中，关于表设计的一些感受。
        最初接触表结构的设计，是所谓的“三范式”的结构。对于像我这样非科班出身的人来说，很多知识都是出了校门再学习。所谓“三范式”，即原子性（字段不可再分）、唯一性（非主键字段依赖全部主键）、无传递依赖(在第二范式的基础上进一步约束)。在我看来这三范式可以看成2个，列不可分没什么好说的，后面2个范式说的都是一个意思，即一行记录的关键字决定了这一行数据的唯一性，但你要记得该拆成2个表时就要拆成2个表，不要将很多业务都放到一个表，造成很多数据冗余以及数据操作异常。
        但讲三范式的书自己都说要是系统都按这个模式来设计那系统就死定了，其最大的一个原因是二、三范式消除数据冗余带来了很多问题。如果没有数据冗余，那么你在实现业务查询的时候就要写很多的表连接语句（不用表连接行不行？可以，你用程序来实现死的更快），在一个业务量比较大的系统中，如果系统中全是这种表连接语句，并且连接的都是千万级的表，那你的系统就扛不住了，这个时候你的系统会出现数据库连接池满，中间件垮掉等现象。好，老板说优化，你把实时查询改成滞后查询，晚上跑批次——把连接语句的结果事先写到一张大表里去。嗯，这是一个解决之道，但你会发现你优化的速度没有问题产生的速度快，命苦的维护程序员。
        这时你还可以上手段，用中间件集群的方法把各子系统拆开，要死只死一个，不要死马拖活马，大家一起死。这时你会发现其实有问题的就是那么几个系统，多半是由于表设计不合理引起的，只要你的老板肯投钱，把这个系统重新翻一遍的话还是有救活项目的希望，但此时你的老板一定是想为什么不重新立个新项目呢？反正国企有的是钱。
        好，当你觉得问题都已经找到原因了，现在只是一个工作量的问题时，你会发现系统现在开始卡首页了，卡完首页每个系统都开始有问题——慢得出奇。此时十之八九是你的系统底层出问题了，我当时发现是底层授权有问题，要讲清这个问题，可以另写一文。有人可能奇怪，为什么此时授权系统开始出问题，当时系统上线验收是怎么通过的。嗯，我只能说上线时数据量不大，用户对系统使用的程度也不深，越用到后来问题越多。
        其实用户授权的检查对于ERP系统来说还真是个问题，一个系统用的时间越长，它增加的页面、人员、组织机构就越来越多，使用的人也越来越多。当系统在使用高峰时，每个用户都在不停的开页面，每个页面都要对用户进行授权检查，这其中包含了页面进入权限检查和按钮使用权限检查（我看网上还有内容权限检查，这我们一般都是在程序中个性化做的，搞到软件功能中还没做过），如果此时授权表设计得不好（比如说有群组套群组，部门套部门，且没有限制层数甚至可以套成回路...我很无语），极易造成锁表，授权表一锁，整个系统就垮了。
        因此，我极力推荐大家把在ERP系统中把用户表、授权表同其它的业务表分离出来，不在同一个数据库，条件允许的话，不在同一服务器。这样，即使你的业务数据库垮掉了，你的框架页面、首页还是好的，你的用户也不至于那么恼火。
        并且，我总是在想，针对用户表、授权表这种写入得少，读取得多的表是不是做10个副本比较好，即你在新增人员、修改授权时一次写入10个一模一样表，而当页面做授权检查时，根据一定的策略分别去读取不同的表，这样可以减缓系统压力，保证系统的稳定性。（谁在实际项目中实现了说一声，天涯的帖子就是分服务器写的，楼主的帖子只需访问www.tianya1.cn即可，由此可见楼主的回复和看客的回复不是一张表）
        但用户表、授权表这种条理比较清晰，结构比较简单的底层表我还是不赞成有数据冗余，3范式还是有它的合理性，如果老板要看综合性报表还是写批次作业。至于那种流程比较长，访问量也大的业务数据表(如一些流程跟踪档)字段还是要一定冗余的，反反复复表连接是不行的。解决并发锁表、知道何时应该冗余总是一个难题，今天先写到这里，以后有什么好想法再补充。