数据库设计的最终追求目标是满足需求与提高性能，根据实际情况的不同可适当调整设计原则。

需求>性能>表结构

数据库三泛式：

三泛式的设计思想为：用时间换取空间，以追求尽量小的数据存储结构。

数据库的每一列都是不可再分的值，以确保数据的原子性（如化学里原子是构成物质的最小单位），简记1NF；字段内容不能是其它字段加工而成，一条数据做一件事情（如总金额=单价*数量），简记2NF；

字段只能与主键为直接关系，不能和其他非主属性为传递关系如：学号Student_No，院校Academy，院校信息Academy_Msg。可通过学号检索院校，进而检索院校信息。这种表结构具有一定的传递关系不符合数据库的第三泛式；

数据库反三泛式：

反三泛式的设计思想为：以空间换取时间，在牺牲存储性能的前提下追求更高的检索效率，主要应用领域为检索功能。

一张表可以没有主键；表中的属性可以依赖于其他的非主属性。表中的属性可以与其他非主属性存在传递关系，记录冗余。

下面介绍几种我在开发中比较常用的数据库检索优化方式，全部违反了数据库的三泛式思想，遵循效率优先的原则。利弊自鉴：

分散计算

例：表结构>>>订单-->商品-->商品附件

如需要在订单表中维护订单总金额属性，需要拿到订单下对应的商品总金额，再拿到商品下对应商品下附件总金额最后进行计算。那么这种方式对于代码的开发以及维护来说比较方便，但数据交互速度或者将数据放到前台计算来说效率都是比较低的，尤其在数据量较大的情况下更为明显。

对于以上等类似情况，我一般采用分散计算：在各表设置对应总金额的冗余，对于Select操作只需要将数据一并取出不需要大量的计算。但是对于Update,Delete,Insert操作，需要维护所有表中的冗余字段。这样开发代码量和维护的难度要求比较高。

总结：分散计算的优点：检索效率高。

分散计算的缺点：由于数据字段的冗余，所以数据分布的范围比较广，开发的代码量大维护的难度较高。

打断设计+跳跃查询

例：表结构>>>订单-->商品-->商品附件-->......

对于层级关系较多的情况，使用关联查询的检索效率是比较低的，而且对于SQL语句的编写复杂度也是比较高的。

对于这种情况可以在主表中维护一个从表的主键集合字段，这也是打断设计的核心思想——冗余，在主表中冗余一个字表主键集合的字段。对于检索SQL的编写就比较简单SELECT* FROM从表 WHERE 从表_ID IN(从表主键集合)；

数据搬家

例：表结构>>>订单-->商品-->商品附件-->......

对于某些使用频率非常高的字段，可以采取冗余的方式，冗余到其他表中。和分散计算的操作思想一致。减少中间传递过程，更为直观的检索出数据。其核心思想同样是冗余，缺点也是数据分布范围较广，对于Update,Delete,Insert操作数据需要同步维护。代码量相对于比较大，后期维护的难度也较高。

如果觉得《四种数据库设计思想》对你有帮助，请点赞、收藏，并留下你的观点哦！