报表开发，看起来只是数据呈现环节的事务，并不起眼，但仔细想想，它涉及的工作范围却非常广。如果把查询和交互分析也认为是报表事务的话（呈现形式本来也是报表），那么可以说，绝大多数 ETL 都是在为报表准备数据而存在的；而且，在数据库中的表，有相当多（经常超过半数）也不是用来存放原始数据，而是为了报表服务的。
不过，有许多程序员对报表开发过程还有些理解误区。对此，我们用三句话来概括报表开发的现状：

报表任务没完没了

在开发应用系统时经常会发现，交易模块已上线很久，而报表模块却迟迟不能结束，总是有新的报表需求源源不断地冒出来。如果开发组在承接项目中仅仅把报表当成应用系统的一个模块而不明确限定其需求范围的话，那通常会死得很难看。

确实，报表天然就具有业务不稳定性。交易系统中常常涉及很复杂的业务规则，随意修改规则可能产生系统的逻辑漏洞，导致数据的不一致，因此，交易系统的规则不会轻易改变。而报表则不同，它只是读取数据，增加更多的报表并不会造成数据的混乱，业务人员在应用过程中想到的新统计需求就会很随意地被提出来，这就造成的报表任务的没完没了。

这是个常态，不要试图规避或消灭它，而要想办法去适应它，也就是建立低成本高效率的应对机制。

自助报表并不管用

既然报表任务天然没完没了，那能不能通过自助报表解决，让业务人员自己去做报表呢？这样报表模块也算是被做完了。

几乎所有的敏捷 BI 产品都会这么宣称，能够让业务人员简单拖拽就能做出自己想要的报表，也确实有许多用户被这些宣传口号吸引了。

但是，不幸的是，自助报表并不管用，大概只能解决 10%-20% 的报表开发需求。

这个原因在于：大多数自助报表功能只能针对单一数据集（就是所谓的 CUBE 了）工作，在某个数据集上进行的汇总统计、查询过滤、排序等动作都没有问题，而需求一旦超出这个数据集的范围后，就无能为力了，又需要技术人员协助去制造新的数据集。有个别功能较强的自助报表产品能够支持多数据集的关联操作，一方面业务人员难以理解（关系数据库的 JOIN 运算很难懂，我们在前面已有论述），实际上没法用；另一方面即使这样也仍然不够，大概也就能再提高 10% 的解决比例。实际业务中提出来的报表需求，大多数都要经过多步运算并涉及多数据集混合运算后才能实现，这种报表就只能程序人员通过编码来完成了。

零编码制作报表只是一句口号

那么，使用报表工具是否能够低成本快速的开发呢？报表工具厂商常常会喊零编码制作报表，这是真的吗？

报表工具经过十多年的发展，确实基本上已经能做到零编码制作了。开发人员可以用工具可视地画出报表式样，再填写一些计算公式把数据与单元格绑定，虽然有些公式也还较为复杂，但毕竟比写程序代码要轻松得多了。而且，由于模板化之后，不再有与应用程序耦合在一起的程序代码，报表也更易于维护修改。

不过，这个便利能力只在呈现环节有意义。而完整的报表开发并不只有呈现，还有复杂的数据准备工作，这就是报表工具无能为力的环节了。从这个意义上讲，报表开发的完整过程仍然无法做到零编码。而且，当前报表的呈现格式在向简单化图形化方向发展，报表工具只是在减轻本来已经在变少的工作量，而相对来讲，数据源准备工作量的占比反而变得更大。

有许多报表工具现在也支持一些数据源的再处理，特别是能做多数据源的报表，这样，确实较多的报表可以直接使用报表工具完成。但剩下的那小部分复杂数据集的报表占用的工作量却要大很多，这是报表开发中心的二八原则，复杂报表在数据量只占二成，但占用工作量却占到八成。项目常常被少数复杂报表给拖累，开发周期非常长。

从上面的讨论，其实已经可以看出当前报表开发的重点已经转移；对此，我们还是三句话来总结：

成熟的报表工具已经能解决呈现环节的问题，如前已述，呈现环节基本上可以零编码实现；报表开发的困难主要是在数据源上，这是目前还没有被普遍工具化的环节，是开发工作的点；大多数性能问题也是数据源造成的或者需要由数据源来解决，性能是报表的老大难问题，看起来是报表环节表现出来的问题，但绝大多数是数据源环节的问题。

数据源环境才是当前报表开发的关键点，而且好的数据源处理机制还能优化报表业务的应用结构，这个问题我们在以往的文章中已经有过阐述。