数据库分库,原来 SQL 和存储过程写的报表咋办?

 

关键词: 分库报表开发 分库报表迁移 分库报表维护 分库 SQL 报表 分库存储过程报表

分库以后,存储过程直接就被判死刑了,铁定不能再用了;SQL 还要看情况(如多表 JOIN),总体来说方向有三个:

一、使用数据库中间件

使用像 Mycat 之类的数据库中间件,报表里的简单 SQL 基本都能延续使用(像 Mycat 支持 SQL92 标准),但对复杂 SQL(嵌套查询和多表 JOIN)就比较麻烦,要考虑全局表等设置。而报表业务里复杂查询会很多,有些还伴随过程和逻辑判断,这时用数据库中间件就有点吃力了。

这里列一下报表场景下使用数据库中间件的缺点:
< 缺点 >

1. 复杂计算支持不足,且无存储过程替代方案;
2. 多样性数据源支持不足,如报表数据来源还有文件或 NoSQL 时;
3. 高耦合,移植性差,仍然存在数据库中间表造成数据库和报表高耦合的问题

参考资料:Mycat 官网

二、使用 JAVA 硬编码

为了弥补数据库中间件的缺点,还可以在应用端使用 JAVA 硬编码为报表准备数据。这样原来的复杂 SQL 和存储过程就可以通过编码实现,而多样性数据源也不再是问题。但硬编码的缺点也很明显:

1. 太难了。用 JAVA 实现报表数据准备,完成各类集合运算对专业程序员都已经很困难(脑补一下写个 group by 的代码量),更别说让报表开发人员来做了;
2. 容易造成报表模块和应用的高耦合。报表的 JAVA 代码和应用代码一起部署,报表模块和应用其他模块紧耦合在一起,没法单独维护;
3. 没法热切换。报表修改以后,要重启整个应用才能生效,而报表却是经常要改…

三、使用支持分库查询的报表工具

有的报表工具直接支持分库查询,像 分库后的报表怎么做 介绍的,主要借助了工具本身提供的脚本计算能力,这样简单 SQL 可以延用,对于复杂计算(复杂 SQL 和存储过程)则通过分步的过程计算来实现,对人员要求也不高。
另外,对多样性数据源的支持也解决了异构源之间的关联计算问题,同时解释执行的脚本支持热切换。这样,整个报表模块就可以单独维护,报表修改也不会影响整个应用(对报表应用解耦感兴趣可以看一下 如何降低报表应用的耦合度 )。当然使用这种方式也有缺点:

1. 适应新的工具。引入新的报表工具势必会带来一定的学习成本。

分库的确会让报表开发和维护环境变得复杂,选用何种方式应对,要充分考虑自身业务和技术资源的实际情况。使用时可以“一二”组合,也可以“一三”组合,或者直接用“三”。