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