网站图片处理方案,建设银行官方网站手机版下载,wordpress上下篇,软文推广平台用存储过程和 JAVA 写报表数据源有什么弊端#xff1f;跟着小编一起来一看一下吧#xff01;我们在报表开发中经常会使用存储过程准备数据#xff0c;存储过程支持分步计算#xff0c;可以实现非常复杂的计算逻辑#xff0c;为报表开发带来便利。所以#xff0c;报表开发…用存储过程和 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 为报表准备数据这个模块可以是由嵌入报表工具的脚本来实现结构可以是这样的脚本要具备完善的计算能力(什么计算都能算)支持多源解释执行允许热切换这些能力。善的计算能力(什么计算都能算)支持多源解释执行允许热切换这些能力。
