我们正在开发一个应用程序，它在Oracle数据库的存储过程中实现业务逻辑。这种方式已经存在了几年。 业务规则多种多样，经常为特定客户定制。
目前，它们与数据管理和数据检索代码混杂在一起。 我一直在考虑提出在BRMS中移动一些逻辑。
我的同事可能会反对，因为：
他们经历过基于PLSQL的当前实现比具有在中间层中实现的逻辑的实现（即Java）更有效。
我们的用户通常需要从我们的软件中获得短的响应时间，因为它还指导他们在工业环境中的操作。
我们的团队规模不大，对业务规则最了解的人也是实现存储过程的人。他们不习惯使用Java，最重要的是，使用PLSQL可以忽略所有关于框架，系统集成和不同层之间映射的错误。
如果我们要切换到除PLSQL以外的其他东西，它必须是不需要大量java编码的东西，并且可能是独立于框架的。
PLSQL允许将应用程序的重量用于昂贵的DBMS。理想情况下，我们希望BRMS和DBMS之间有效整合。
为了更好地提出我的建议，我需要一些关于以下问题的客观数据：
我在网上看了几个参考文献。不幸的是，他们中的大多数都比较了纯Java代码与存储过程或纯Java代码与BRMS的实现。我找不到比较存储过程和BRMS的任何内容，或描述如何将存储过程解决方案与BRMS集成。
非常感谢。
答案 0 :(得分：1)
Oracle有一个内置的规则引擎，没有广泛宣传。但它是用PL / SQL构建的，当然它的接口是PL / SQL。
我已将它用于一些ETL任务，但没有任何需要高性能的批量数据。如果你愿意牺牲一些表现以获得灵活性，我会推荐它。
http://docs.oracle.com/cd/B19306_01/appdev.102/b14288/toc.htm
答案 1 :(得分：0)
如果选择一个成熟的引擎，那么规则引擎的性能很可能比访问数据库以检索和评估规则的系统的性能要好得多。我们目前使用的引擎可以在大约50毫秒内针对单个复杂规则评估大约200万个对象。那是200万个复杂的物体。
引擎的一个功能应该是允许业务人员创建和管理规则的UI，而不是程序员。有了适当的引擎，程序员就不应该创建和管理规则。你可能正在看开源引擎（Drools等）。他们通常会忽略这一点。这就是为什么你会有一个印象，你的家伙必须学习Java才能创建业务规则。这是一个错误的假设开始。
业务规则引擎的重点是从主代码中抽象出业务逻辑。您的基于数据库的系统不提供普通BRE的抽象级别。我不知道你的系统，但基于我对引擎和“数据库规则系统”的了解，我对此有99.9％的肯定。您需要一个数据库来存储规则。就是这样。
这取决于您选择的引擎。对于IT而言，培训通常很少，而对于业务而言，培训的平均水平则略高。
希望这有帮助。