业务逻辑:从存储过程转移到BRMS。赞成与反对

Question

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

目前，它们与数据管理和数据检索代码混合在一起。我一直在考虑在BRMS.中移动一些逻辑。

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

1. 他们体验到，当前基于PLSQL的实现比在中间层中实现逻辑的实现效率要高得多，即用Java实现。 我们的用户确实确实需要从我们的软件中获得较短的响应时间，因为它也指导他们在工业环境中的操作。
2. 我们的团队并不大，最熟悉业务规则的人也是实现存储过程的人。它们不习惯于使用Java，而且最重要的是，使用PLSQL允许我们忽略有关框架、系统集成和不同层间映射的所有关键问题。 如果我们要切换到PLSQL以外的其他东西，它必须是不需要大量java编码的东西，而且可能是独立于框架的.。
3. PLSQL允许在昂贵的DBMS上利用应用程序的权重。理想情况下，我们希望在BRMS和DBMS之间实现有效的集成。

为了更好地提出我的建议，我需要一些关于以下问题的客观数字：

1. 从存储过程迁移到BRMS的性能损失
2. DBMS与BRMS的集成
3. 与PSLSQL和纯java代码提供的抽象相比，BRMS提供的抽象
4. 转换所需的培训

我在网上查了一下，发现了一些参考资料。不幸的是，它们中的大多数比较的实现要么是纯Java代码与存储过程，要么是纯Java代码与BRMS。我找不到任何比较存储过程和BRMS的东西，也找不到描述如何将存储过程解决方案与BRMS集成的方法。

非常感谢。

Answer 1

1. 如果选择一个成熟的引擎，规则引擎的性能很可能比访问数据库检索和评估规则的系统的性能要好得多。我们目前使用的引擎可以在大约50毫秒内根据一个复杂的规则来评估大约200万个对象。那是两百万复杂的物体。
2. 引擎的一个特性应该是允许业务人员创建和管理他们的规则的UI，而不是程序员。有了适当的引擎，程序员永远不应该创建和管理规则。您可能正在查看开源引擎(Drools等)。他们一般都忽略了这一点。这就是为什么您有这样的印象，您的手下必须学习Java才能创建业务规则。这是一个错误的假设。
3. 业务规则引擎的全部目的是将业务逻辑从主代码中抽象出来。基于数据库的系统不提供正常BRE所能提供的抽象级别。我不知道你的系统，但我对此有99.9%的肯定，根据我对引擎和“数据库规则系统”的了解。您需要一个数据库来存储规则。就这样。
4. 这取决于你选择的引擎。培训对于IT来说通常是最少的，对于商业来说则是中等水平的。

希望这能有所帮助。

Answer 2

甲骨文有一个内置的规则引擎，这个引擎没有被广泛宣传。但是，它是用PL/SQL构建的，当然它的接口是PL/SQL。

我已经将它用于几个ETL任务，但对于批量数据没有任何高性能要求。但是，如果您愿意为了灵活性而牺牲一些性能，那么我建议您这样做。

01/appdev.102/b14288/toc.htm