前言
在设计关系型数据库时,我们从课上的学习得知,需要参照不同的范式及原则,设计表结构与表关系。在课上,我们关注的角度更多是,设计要符合范式,保证数据不冗余。但在实际的开发设计中,我们往往要从更多角度思考数据库的设计原则,根据不同的需求场景,进行不同角度的侧重。比如开发是否便捷,表结构是否易维护,查询效率是否达到要求等等。
设计原则
一般的企业级应用数据库中,对于数据的冗余是有一定容忍性的,但对于数据库增删改查的效率,往往会有很高的要求。这时候,我们之前遵循的一些原则,就要做出不同程度的改变。比如,之前依据少冗余原则,参考的设计三大范式,可能在数据库增删改查效率的面前,就要做一些妥协了。
在设计能容忍冗余、重视效率的数据库时,个人认为,主要需要考虑以下几方面:
-
每个表增删改的范围尽量都在本表进行
这条原则也是与三大范式有些相悖的,但这样做的好处非常明显。
第一,还是从开销角度出发,这样做的话,增删改的开销通常比多表要低。
第二,这样便捷开发,在数据存储过程中,如果涉及多表操作,表越多,处理业务逻辑的代码就越多,在开发时难度也就越大。
第三,可维护性高,这一点和第二点有点重合,但就是因为单表设计的业务代码会相对简单,所以日后的维护也会相对容易,反之,多表的业务代码庞杂,日后的维护也会非常的困难。 -
通过主键体现对应关系,且应体现流程顺序
企业级应用最大的难题就是梳理业务,理清业务模块之间的对应关系。在数据库中,表中包含的主键除了要体现对应关系外,还应该体现生成顺序或流程顺序的逻辑。 -
每个表尽量代表一个业务模块,尽量记录模块中的所有字段
由第一个原则推理出这个原则,因为在本表增删改查的开销小,所以,如果一个表足够的内聚,那么这个表就要尽量记录模块中的所有字段。
tips:- 如果之后业务模块内字段过多,可以进行分表处理,但如果一开始就是分开设计的,那么处理会很麻烦。
-
中间表不可以随意使用
在充分遵循三大范式的前提下,我们的设计就会有很多的中间表(关系表)。但如果在两个表中,其中有一个表增删改频繁,那么从效率角度而言,这样的设计就是不合格的。这样的设计确实会减少很多数据冗余,但是也会大大增加每条数据增删改的开销。所以从一般的企业级应用场景来看,中间表不可以随意使用。
通过了解中间表的使用缺陷,我们也就知道了什么时候可以使用中间表。当左表和右表都没有非常频繁的改动需求,但有非常频繁的联表查询需求的时,我们就可以运用中间表,来提升查询效率,并减少数据冗余。
总结
经过了几次设计我发现一个大道理哈哈,其实技术最后还是要为具体的业务场景服务。很多计算机问题都是需要时间和空间的开销相互妥协,在具体的业务场景中,往往也是如此。三大范式只是一般设计数据库的基本理念,通过三大范式,我们可以建立一个小冗余、表结构合理的数据库,但就像之前说的,表结构合理不代表符合业务需求,如有特殊业务情况,就要按特殊情况对待。
一般而言,需求 > 性能 > 表结构(冗余)。
参考文献
https://blog.csdn.net/qq_26878363/article/details/81533273