关系型数据库设计规范感悟

 在设计关系型数据库时，我们从课上的学习得知，需要参照不同的范式及原则，设计表结构与表关系。在课上，我们关注的角度更多是，设计要符合范式，保证数据不冗余。但在实际的开发设计中，我们往往要从更多角度思考数据库的设计原则，根据不同的需求场景，进行不同角度的侧重。比如开发是否便捷，表结构是否易维护，查询效率是否达到要求等等。

[[378474]]

设计原则

一般的企业级应用数据库中，对于数据的冗余是有一定容忍性的，但对于数据库增删改查的效率，往往会有很高的要求。这时候，我们之前遵循的一些原则，就要做出不同程度的改变。比如，之前依据少冗余原则，参考的设计三大范式，可能在数据库增删改查效率的面前，就要做一些妥协了。

在设计能容忍冗余、重视效率的数据库时，个人认为，主要需要考虑以下几方面：

1、每个表增删改的范围尽量都在本表进行

这条原则也是与三大范式有些相悖的，但这样做的好处非常明显。

第一，还是从开销角度出发，这样做的话，增删改的开销通常比多表要低。

第二，这样便捷开发，在数据存储过程中，如果涉及多表操作，表越多，处理业务逻辑的代码就越多，在开发时难度也就越大。

第三，可维护性高，这一点和第二点有点重合，但就是因为单表设计的业务代码会相对简单，所以日后的维护也会相对容易，反之，多表的业务代码庞杂，日后的维护也会非常的困难。

2、通过主键体现对应关系，且应体现流程顺序

企业级应用最大的难题就是梳理业务，理清业务模块之间的对应关系。在数据库中，表中包含的主键除了要体现对应关系外，还应该体现生成顺序或流程顺序的逻辑。

3、每个表尽量代表一个业务模块，尽量记录模块中的所有字段

由第一个原则推理出这个原则，因为在本表增删改查的开销小，所以，如果一个表足够的内聚，那么这个表就要尽量记录模块中的所有字段。

tips：

如果之后业务模块内字段过多，可以进行分表处理，但如果一开始就是分开设计的，那么处理会很麻烦。

4、中间表不可以随意使用

在充分遵循三大范式的前提下，我们的设计就会有很多的中间表(关系表)。但如果在两个表中，其中有一个表增删改频繁，那么从效率角度而言，这样的设计就是不合格的。这样的设计确实会减少很多数据冗余，但是也会大大增加每条数据增删改的开销。所以从一般的企业级应用场景来看，中间表不可以随意使用。

通过了解中间表的使用缺陷，我们也就知道了什么时候可以使用中间表。当左表和右表都没有非常频繁的改动需求，但有非常频繁的联表查询需求的时，我们就可以运用中间表，来提升查询效率，并减少数据冗余。

[[378475]]

总结

经过了几次设计我发现一个大道理哈哈，其实技术最后还是要为具体的业务场景服务。很多计算机问题都是需要时间和空间的开销相互妥协，在具体的业务场景中，往往也是如此。三大范式只是一般设计数据库的基本理念，通过三大范式，我们可以建立一个小冗余、表结构合理的数据库，但就像之前说的，表结构合理不代表符合业务需求，如有特殊业务情况，就要按特殊情况对待。

一般而言，需求 > 性能 > 表结构(冗余)。