用存储过程和 JAVA 写报表数据源有什么弊端？

我们在报表开发中经常会使用存储过程准备数据，存储过程支持分步计算，可以实现非常复杂的计算逻辑，为报表开发带来便利。所以，报表开发中这样的存储过程并不少见：

3008 行，141KB 的存储过程，会给报表开发带来什么不好的影响？

1. 编辑调试性
存储过程难以编辑调试，这样几千行存储过程的开发周期往往要以周或月计，这样会严重影响报表的开发效率，而业务提的报表需求似乎都“很急”。

2. 维护性
相对开发的一次性，维护的工作可能要经常做。实际业务中报表经常会修改，这种现象叫做报表业务的稳定性差。报表的数据准备逻辑变化，修改上千行的存储过程对绝大多数报表开发人员来说都是噩梦。

有时这样的报表会分两拨人来做，DBA 或专业程序员负责编写存储过程给前端报表开发人员做报表，这样就避免了报表开发人员写存储过程。但这样报表修改的流程会变长，修改一张报表涉及多个人员之间沟通（还包括业务人员），如果负责报表前后端的两拨人隶属不同的团队就更麻烦了。

3. 知识传承
从维护性可以直接引出另一个“知识传承”的问题。还是拿上面的报表为例，如果一个新人要改上面的报表，你觉得他要多久能看懂存储过程，改完报表？

当然，这个问题还涉及很多管理方面的手段，单纯从技术本身来看，这样的报表想要很好地传承知识是很难的。

4. 安全性
对存储过程的修改需要较高的数据库权限，而报表经常要改就要经常操作数据库，这对数据库安全也是一个隐患，同样需要强管理机制才能保障一二。

5. 移植性
现在绝大多数规定禁止使用存储过程的原因，首当其冲的就是存储过程没有移植性。如果未来数据库发生变化需要迁移，不管将来是更换数据库类型，还是系统扩展（分表分库），大量无法移植的存储过程绝对是最头疼的问题。

当然，“换库”这件事情即使在今天仍然不会频繁发生，但是只要发生一次就够受了（有国产化或系统扩展预期的就要注意了）。

6. 耦合性
从维护性、安全性和移植性看来，存储过程会导致报表应用（前端）和数据库（后端）紧耦合。紧耦合除了会导致前面的三个问题外，还会让数据库编的臃肿，影响数据库性能。

重要的事情说好多遍，报表的业务不稳定，报表除了经常增加和修改，有时还会删除（不用了），而为这个报表准备的存储过程还在数据库里，这时想要删掉这个存储过程就比较难了。

为什么？

因为你不知道是不是还有其他程序在共用这个存储过程，删除会不会对其他程序产生影响。结果就是数据库的存储过程越积越多导致数据库臃肿，而有的存储过程还会涉及自动运行，虽然存储过程可能不再使用，但仍然在消耗数据库资源，长此以往数据库性能下降就成为必然了。

7. 多源支持
存储过程运行在封闭的数据库内，无法进行跨多数据源混合计算。关于多源问题，几年前在报表开发还不显著，那时大家都用关系库；但现在不一样了，同一个报表的数据可能来自多个不同类型的数据源（RDB/NoSQL/TxT/Excel/Hadoop/ES 等等），这时存储过程就无能为力了。

如何搞定这些问题？
有没有办法解决存储过程带来的这些问题呢？

当然有！

没有什么是硬编码解决不了的！用 JAVA 替代存储过程，脱离数据库运行来解决上面的问题（自行搜索 SOA 和微服务理念）。存储过程一个显示的好处是可以分步实现报表数据准备逻辑，这个优点 JAVA 也有，甚至比存储过程更彻底，说句文绉绉的话：JAVA 的离散性更好。

只是 JAVA 写起来比较麻烦，对于报表开发人员来讲太难了，如果还要加一个修饰词那就是太 XX 难了。存储过程使用的 SQL 语言非常适合做集合运算，分组汇总一句 group by 就写出来了，反观 JAVA 就不具备这个优点了，分组汇总可能要写上几十上百行才行（类库缺失会让开发复杂度急剧上升，想想你为什么不用汇编写程序而要用 JAVA？）。

JAVA 还有一些其他的问题也不容忽视。

不支持热切换
JAVA 还有一个非常致命的缺点，就是不支持热切换。报表经常要改（又来一遍），修改报表数据源以后还要重新编译、重启应用才能生效，对绝大多数业务系统都是不能接受的。报表讲究的不仅是查询立等可取，修改也要实时生效才行。

报表与应用紧耦合
与使用存储过程会导致报表与数据库紧耦合类似，用 JAVA 准备报表数据源会导致报表模块和应用的其他业务模块紧耦合不宜维护。

我们知道，报表大多数情况都是作为一个模块集成到应用系统提供报表查询服务，集成的方式可以是 API（jar 包）方式紧集成；也可以将报表单独发布成服务，通过服务调用的方式松集成，这样报表服务器产生的任何压力或问题都不会影响应用系统（高可用）。
*API 紧集成后，由于报表数据源是 JAVA 写的，这样就要和主应用的代码一起打包，无法作为独立的模块维护，而未来想要拆分也基本不可能了；
* 服务松集成则完全无法实现。

所以，用 JAVA 写报表数据源虽然可行，但也不是特别理想。

那有没有其他办法呢？

我们比较一下存储过程和 JAVA 的优缺点可以发现，解决问题应该是沿着继承二者优点，改进缺点的方向进行。清晰起见，总结一下需要的点。

把主要的点列了一下，我们的目标就是找到支持这些点的技术手段（问号所在行）。

易开发、易维护
这注定了这些能力应该是报表工具内置的，这样报表开发人员自己就能使用工具搞定报表开发，而不必依赖其他人或团队；

热切换
热切换要求这个技术应该是解释执行的，这样才能做到实时修改实时生效；

支持多源
能够对接多种不同类型的数据源进行混合计算，比如文本和数据库表的 join；

低耦合、可移植
数据准备能力和报表呈现能力都报表内置了，自然与应用和数据源都解耦了，未来系统扩展自然毫无压力。

这样我们可以很容易想到在报表端增加一个计算模块，来替代存储过程或 JAVA 为报表准备数据，这个模块可以是由嵌入报表工具的脚本来实现，结构可以是这样的

脚本要具备完善的计算能力（什么计算都能算），支持多源，解释执行允许热切换这些能力。

这才是报表工具的未来！

参考资料：
怎样减少报表开发中对存储过程的依赖
如何应对报表开发中的复杂逻辑