另类数据库优化，程序员的小心思

在数据库优化的过程中，领教过各种，技术的，非技术的，数据库赋予的特性的，数据库表人工设计中优化非范式的设计。其实众多优化的想法无非是从接受数据的开始通过精准定位需求，格式化数据库表，在设计表时就考虑部分查询的优化，以及后期进行数据表的归档等等工作。

在深入就是利用缓存的技术，将数据预读进来，增加数据提取的时效性，加快数据提取的速度而已。而这些大部分都是 NF。

今天要说的是，我们公司的程序员想出的一个方法，加快数据的某些提取速度，减小表的查询的耦合，提高客户的使用观感的一种方法，这也算是另类的一种数据提取的方式。

画个图说的清楚些，例如某个客户需要输出的信息需要 表 A B C D 组成，多表的无论是子查询，LEFT JOIN ， 还是 EXISTS 等等数据量小还好，如果数据量大，那就的在关联字段上建立索引，而建立索引太多，如果表的数据插入频繁又是插入性能低下，这是先有蛋还是先有鸡的问题。

而聪明的程序员，在充分了解客户需求以及客户需求不断变化的情况下，想出了，预先将 B C D 表的信息合并，减少后期数据表查询的耦合，加快信息的提取，而最终实现数据的快速高性能的提取。

还是的画张图，来说的更清楚， 程序员在数据输入的时候就通过程序来自动生成了 F 表，它是一个根据客户需求的内容来生成的一个单独的表，不需要数据库做任何运算，而是在程序端处理，提前将用户日后需要查询的数据做了一个表。

可能有的DBA 会说，切，这不就是视图的概念，ORACLE 有物化视图的概念，SQL SERVER 有索引视图的概念，都可以轻松的完成上面的工作。我想说的是 NO NO NO 。

虽然通过视图可以完成这个工作，但视图哪怕是 物化视图，或索引视图，它们也都要通过数据库的运算,数据提取，才能获得数据，并存储，或者不存储，每次调用在进行计算。这样的方式DBA已经很熟悉了，但弊端也是显而易见的，无法摆脱数据库自己的运算和数据提取，这也是产生性能瓶颈的可能原因。

所以DEVELOPERS 已经在程序中，自己建立了自己的物化视图，后期查询仅仅需要查询表A + 表 F 即可达到目的。 在我看来这真的是一个好方法，虽然它也有的局限性，但开发的优化精神和不默守陈规的想法，值得“赞”