java - 业务逻辑:从存储过程转移到BRMS。利弊

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center作为指导。
                            
                        
                    
                
                7年前关闭。
            
        

我们正在开发一个应用程序，该应用程序在Oracle数据库上的存储过程中实现业务逻辑。已经有几年了。
业务规则是多种多样的，并且通常针对特定客户进行定制。

当前，它们在某种程度上与数据管理和数据检索代码混合在一起。
我一直在考虑提议在BRMS中移动一些逻辑。

我的同事可能会反对，因为：


他们体验到，当前基于PLSQL的实现要比在中间层（即Java）实现逻辑的效率要高得多。

我们的用户确实确实需要从我们的软件获得较短的响应时间，因为它还指导他们在工业环境中的操作。
我们的团队并不庞大，并且最了解业务规则的人员也是实施存储过程的人员。它们不习惯与Java一起使用，最重要的是，使用PLSQL使我们可以忽略关于框架，系统集成以及不同层之间的映射的所有麻烦。

如果我们要切换到PLSQL以外的其他工具，则它必须不需要大量Java编码，并且可能与框架无关。
PLSQL允许将应用程序的权重利用到昂贵的DBMS上。理想情况下，我们希望BRMS与DBMS之间进行有效的集成。


为了更好地表达我的建议，我需要一些有关以下问题的客观数据：


从存储过程到BRMS的性能损失
DBMS和BRMS之间的集成
BRMS提供的抽象与PSLSQL和纯Java代码提供的抽象相比
切换所需的培训


我在网上查看了一些参考。不幸的是，大多数人将纯Java代码vs存储过程或纯Java代码vs BRMS的实现进行了比较。我找不到将存储过程和BRMS进行比较的任何内容，也没有描述如何将存储过程解决方案与BRMS集成。

非常感谢。

最佳答案

如果选择一个完善的引擎，则规则引擎的性能很可能会比访问数据库以检索和评估规则的系统的性能好得多。目前，我们使用的引擎可以在大约50毫秒的时间内根据一条复杂规则评估大约200万个对象。那是200万个复杂对象。
引擎的功能之一应该是允许业务人员（而非程序员）创建和管理其规则的UI。使用适当的引擎，程序员永远都不应创建和管理规则。您可能正在研究开源引擎（Drools等），他们通常会错过这一点。这就是为什么您给人留下了这样的印象，即您的员工必须学习Java才能创建业务规则。首先，这是一个错误的假设。
业务规则引擎的全部目的是从主代码中抽象您的业务逻辑。您的基于数据库的系统不提供正常的BRE提供的抽象级别。我不知道您的系统，但根据我对引擎和“数据库规则系统”的了解，我对此表示满意99.9％。您需要一个数据库来存储规则。就这样。
这取决于您选择的引擎。对于IT而言，培训通常是最少的，而对于企业而言，则是中等的。


希望这可以帮助。