数据库分库，原来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. 适应新的工具。引入新的报表工具势必会带来一定的学习成本。
分库的确会让报表开发和维护环境变得复杂，选用何种方式应对，要充分考虑自身业务和技术资源的实际情况。使用时可以“一二”组合，也可以“一三”组合，或者直接用“三”。
以上是 数据库分库，原来SQL和存储过程写的报表咋办？ 的全部内容， 来源链接： utcz.com/z/534106.html
