大道至简 三招搞定ERP报表.docxVIP

PAGE 1 PAGE 1 大道至简 三招搞定ERP报表  报表无疑是ERP系统中用到的最频繁的单据之一。  报表无疑是ERP系统中用到的最频繁的单据之一。比如每天选购要打印选购明细帐；仓库每天要导出收货或者出货明细；销售每天要打印订单明细等。故报表的设计在ERP系统开发中占据大半江山。不过笔者在实际工作中也发觉，有些开发人员在设计ERP报表时，太过于复杂。  有一次，一家企业向我提出了如下需求：他们期望能够出一份报表，报表的内容包括四个部分。一是成品零件的用量、零件的最小选购量等信息；二是当月零件的选购量信息(具体的选购订单等资料)；三是当月零件的出库信息(具体的出货记录)；四是零件的安全库存信息。然后，依据这些信息计算出当月需要补下的满意安全库存的数量。从这个需求中可以看出，其主要设计到产品基本资料、选购、仓库等三个模块的内容。这么复杂的报表，从技术上来说，实现的难度并不是很大。但是从实用性角度考虑，或者从精确性来看，又会有什么结果呢？  1报表越复杂，精确性越难把握  一般来说，报表越复杂，其精确性余越难以把握。其实抛开ERP系统，从统计学的角度，我们也可以得出这个结论。如下图所示，现在有三个抽屉。每个抽屉中都有0-9十个数字。假如现在从每个抽屉中随便抽出两个数字，最终组成一个三位数。那么最终有几种结构呢？这是一个排列组合的问题。  再回过头来看一下这个表单的内容。现在这个表单有三个模块的数据构成。就似乎这三个抽屉。当然其抽屉中的数据远比10个数字要负载的多。我们设想一下，从单个模块来看。可能企业允许的误差率是5%。即100条记录中，允许有5条记录与实际有偏差。现在三部分信息共同组成的一张报表，而且最终需要依据三部分信息的内容计算出一个值，那么这个出现错误的记录会有多少呢？这又是一个排列组合的问题。如假设每部分信息中，都有5条件有偏差，那么最终理论上的错误记录是125条。明显这个错误率比较大。同时也可以看出，当涉及到的基础表数量越多，涉及到的模块越多，其最终结果的精确性就越难以保障。而当数据的精确性不高时，其实用性也就相应的降低。  2报表关联越多，性能也会下降  报表越复杂，其涉及到的后台数据库基础表也就越多。虽然多表之间的关联查询是允许的，但是关联的关键字越多，其查询的效率也就越低。特殊是在关联条件中，有时候采用的并不是关键字之间的关联。如有可能日期(字符数据类型的关联)之间的关联，此时查询的效率会更低。再加上比较复杂的Where规律推断语句，复杂报表的查询时间会很长。如笔者测试过，根据上面这个用户的需求，设计出的报表其查询的时间需要近三分钟，而且是已经优化过的查询。另外，这个报表的查询由于涉及到众多的基础表，数据库基本上需要访问硬盘上的数据文件，而不能够使用缓存。这就有可能会导致比较严重的硬盘I/O冲突。从而影响到其它数据的查询效率。  故从数据库与应用软件的整体性能考虑，也不建议采用比较复杂的报表视图。究竟性能降低、查询的时间比较长时，报表的实用性也在降低。  3设计复杂报表的留意事项  为此，从原则上是禁止设计超过两个模块的数据报表，最好是将报表的范围限制在单个模块下。如此的话，无论从性能还是从数据的精确性上都会有所保障。但是，假如用户的确有需要实现比较复杂的报表，在这种状况下，该如何处理呢？为此笔者依据自己的项目经验，提出了以下几个建议。  使用固化视图来改善数据库的性能。  复杂报表所导致的不利影响，其首当其冲的是报表查询时速度会很慢，性能很低。为此在涉及到复杂报表时，开发人员可以考虑采用固化视图来改善数据库的性能。如在Oracle数据库中，固化视图又叫做物化视图。通固化视图，可以用于预先计算并保存表连接或者聚集等耗时比较多的操作结果。简洁的说，就将某个报表的查询结果存储在一张单独的表中。如此的话，在执行查询时，就可以避免使用这些耗时的操作，同时削减磁盘的I/O冲突，从而以最短的时间得到用户想要的结果。一般来说，固化视图对于复杂的报表来说，能够供应三方面的作用。如可以提高查询的性能。如固化视图对于应用来说是透明的，增加和删除物化视图不会影响应用程序中SQL语句的正确性和有效性。如当基表发生变化时，物化视图也会同时更新。不过需要留意的是，物化视图也会带来一些负面影响。如物化视图的数据会保存在硬盘中，为此就会占用额外的存储空间等。总之，在设计比较复杂的报表时，开发人员可以与数据库工程师商量，能够采用固化视图。假如可以的话，需要尽量采用固化视图。  复杂的报表当设计到多表时，最好采用模块化的设计。  如某视图，其涉及到的基表有近20张。那么在设计视图时，要避免将其放在一个SQL语句