|
四种高效数据库设计思想——提高查询效率：设计数据库表结构时，我们首先要按照数据库的三大范式进行建立数据。 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的值）)）——货物里本身就有厂家的厂家名信息等。操作完成！ 三次查询就可以拿到最终结果。 数据搬家： 数据搬家也是数据库优化的一种：表级别的数据冗余，再添加一个出口报运单时，就能得到这个报运单所报运的货物和附件，如何实现报运单下货物和附件的数据，实现原理就是首先找到购销合同对象，再得到购销合同下的货物和附件，针对货物和附件分别进行数据拷贝。 应用： 传统：通过商品明细——货号——查询货物对象——对象导航得到附件 数据搬家：商品明细对象导航——附件信息 之前查三次,现在查两次就可以得到报运商品的信息。 冗余没问题，效率第一位。 小结： 以上四种方式均违反了数据库的三大范式，采用了数据冗余方式，小编不是主张大家采用数据冗余，而是在三大范式和查询效率发生冲突的情况下，我们采用违法三大范式，选择效率优先原则！这四种方式，是我工作中用到的，效率较高的四中方式，与大家分享！ |
|
|
