我们正在开发一个应用程序,它在 Oracle 数据库上的存储过程中实现业务逻辑。几年来一直如此。业务规则多种多样,并且经常针对特定客户进行定制。
目前,它们在某种程度上与数据管理和数据检索代码混合在一起。 我一直在考虑提议在 BRMS 中移动一些逻辑。
我的同事可能会反对,因为:
他们体验到,当前基于 PLSQL 的实现比在中间层(即 Java)中实现逻辑的实现要高效得多。
我们的用户通常确实需要我们的软件提供较短的响应时间,因为它还指导他们在工业环境中的操作。
我们的团队并不大,最了解业务规则的人也是实现存储过程的人。它们不习惯与 Java 一起工作,最重要的是,使用 PLSQL 可以让我们忽略有关框架、系统集成和不同层之间映射的所有麻烦。
如果我们要切换到 PLSQL 以外的其他东西,它必须是不需要大量 Java 编码并且可能独立于框架的东西。
PLSQL 允许在昂贵的 DBMS 上利用应用程序的权重。理想情况下,我们希望在 BRMS 和 DBMS 之间进行有效集成。
为了更好地提出我的建议,我需要一些关于以下问题的客观数据:
- 从存储过程转移到 BRMS 的性能损失
- DBMS 和 BRMS 之间的集成
- BRMS 提供的抽象与 PSLSQL 和纯 Java 代码提供的抽象相比
- 转换所需的培训
我在网上查了一些参考资料。不幸的是,他们中的大多数人比较了纯 Java 代码与存储过程或纯 Java 代码与 BRMS 的实现。我找不到任何比较存储过程和 BRMS 的东西,或者描述如何将存储过程解决方案与 BRMS 集成的任何东西。
非常感谢。