四种高效数据库设计思想——提高查询效率

【开篇】

设计数据库表结构时，我们首先要按照数据库的三大范式进行建立数据库。

1. 1NF每列不可拆分

2. 2NF确保每个表只做一件事情

3. 3NF满足2NF，消除表中的依赖传递。

三大范式的出现是在上世纪70年代，由于内存资源比较昂贵，所以严格按照三大范式进行数据库设计。而如今内存变得越来越廉价，在考虑效率和内存的基础上我们可以做出最优选择以达到最高效率。建立数据库先按照三大范式进行建立，如果出现由于业务逻辑查询而造成效率低的现象，可以违反三大范式进行修改数据库。总之，效率第一。

分散计算：

分散计算的优缺点：

缺点：代码量太大、维护困难。

优点：提高运行效率、查询速度快、提高了数据的检索效率。

什么情况下使用分散计算:

合同和货物是一对多的关系，货物和附件是一对多的关系。如果按照传统的方式获得某个合同的总金额：那么我们需要从查询合同———>合同下的货物——>货物下的附件。从页面进行计算：合同金额=货物单价数量+附件单价数量 （每个货物的总金额计算出来+每个货物下所有附件的总金额计算出来 然后加到一起构成合同的总金额）这样页面上上的数据计算量是非常庞大的，所以就会造成用户少的时候页面加载速度还可以，用户量一旦多起来就会造成页面加载很慢，用户不愿等待的现象出现。

措施：

合同、货物、附件中分别加入总金额的冗余字段：可以在平时添加货物时，添加附件时，分别计算出货物总金额，附件总金额，加到数据库中，在更新购销合同金额。这样就相当于将一次更新的工作量分散到平时的多次计算过程中，所以查询购销合同总金额的速度就会很快。从数据库查询，远比从页面计算效率要高N多倍。

打断设计思想：

当关联查询的层级大于4层时，就要考虑打断设计，这样可以借助跳跃查询实现查询速度翻倍。

就是在传统的一对多关系中，都会在多方加入一个一方的主键作为外键，但在是在打断设计思想的指导下，不会这样实现，它会在一的一方加入一个冗余字段，用于保存多的一方的主键，并且指定分隔符进行分隔。虽然多的一方没有加入一的一方的主键做外键，但仍保持了原有的一对多关系。

真正的实现原理：就是通过打段字段，实现数据的冗余，从而一样的可以解决一个报运单下多个购销合同的问题。

1.传统做法：

出口报运单对象——>加载出购销合同的集合——>遍历出每个购销合同——>通过购销合同得到货物——>再通过货物得到附件。

2.打段设计基础上的做法：

出口报运单——>得到它的一个字段（购销合同id形成的集合）——>直接到货物表中进行查询（from ContractProduct cp where cp.contract.id in(购销合同id形式的集合)）

打断设计+跳跃查询做法：

按照传统设计方法：

财务如果想知道这笔款项从哪个货物/附件是从哪个生产厂家生产的：一个环节套一个环节，不可跳跃。一对一对应关系，通过对象导航得用很多HQL语句才能够导到厂家信息。关联7级才能找到目标对象。加载速度一定很慢！

打断设计+跳跃查询做法应用：

本模块的数据表：





装箱单和报运单：

跳跃查询

跳跃查询的前提：提前采用打断设计表的优化，而打断设计思想的关键是字段的冗余，就是在报运单中加入一个冗余字段吗，放入购销合同的id集合。

财务人员得到财务报运单ID——>装箱单（Export_IDS）——>报运单（Export_ID in(Export_IDS)）——>跳跃查询直接查询货物（from CONTRACT_PRODUCT WHERE CONTRACT_PRODUCT_ID IN (购销合同里面合同编号的集合（正好是用逗号隔开的一堆值即CONTRACT_IDS的值）)）——>货物里本身就有厂家的厂家名信息等。操作完成！

三次查询就可以拿到最终结果。

数据搬家：

数据搬家也是数据库优化的一种：表级别的数据冗余，再添加一个出口报运单时，就能得到这个报运单所报运的货物和附件，如何实现报运单下货物和附件的数据，实现原理就是首先找到购销合同对象，再得到购销合同下的货物和附件，针对货物和附件分别进行数据拷贝。

应用：

传统：通过商品明细——货号——查询货物对象——对象导航得到附件

数据搬家：商品明细对象导航——附件信息

之前查三次,现在查两次就可以得到报运商品的信息。

冗余没问题，效率第一位。

原理图：

小结：

以上四种方式均违反了数据库的三大范式，采用了数据冗余方式，小编不是主张大家采用数据冗余，而是在三大范式和查询效率发生冲突的情况下，我们采用违法三大范式，选择效率优先原则！这四种方式，是我工作中用到的，效率较高的四中方式，与大家分享！