昨天在一次研讨会上，一同志说他为甘肃某高校做了一个建筑部门的管理网站用了足足70多张表，我一听一惊，随口来句，这哥们扯吧！
我认为学校的单个部门业务不论多么复杂，这么多表也并不利于实际系统开发，况且单个部门也不可能有那么复杂的业务。那么站在这哥们的角度理解，理由只有一个，他把表拆分的非常的细致，单个表字段很少，功能非常单一。
好像也可以理解，但是70多个表，俺从业多年几乎也没有见过几个如此庞大的工程。总是感觉怪怪的，于是总想从理论上分析下他的这样设计是否合理。数据库设计相信大部分开发人员都知道要遵守设计范式咯，这部分内容可以参考我的上篇范式文章，那么我能否从范式着手，做个分析呢？问题来了，我也有些困惑了，下面讲讲得出的结论：
范式作为数据库设计的理论基础，其实并不完善，有些情况不适合实际开发。范式的指导原则是尽量做到清晰、简单、明了，把复杂的关系给拆简单了。但是问题出来了，实际开发要考虑高效，简捷，尽量避免多表查询。而这一原则恰恰和范式理论冲突，那么如何去做呢？我想每个人都会有不同的做法，当然最重要的是自己工作经验的积累，和对实际业务的了解，去设计真正适合自己的数据库结构。
这是一位高人的说法：
所谓范式指的是设计高效的方便扩展数据库的准则，但是实际之中也只是作为一个参考，因为按照标准设计范式，查询很复杂，效率不高，不一定适合实际开发。那么实际的工作之中，对于实际数据库设计只有一个原则：“根据业务尽可能的减少多表查询”。
最后，对于70多张表的哥们来说，只能说符合范式的简单化，但是实际中70多个表的多表联合查询对于开发人员来说并不是一个good idea。
欢迎大家一起讨论…
时间： 2024-08-29 07:21:22