java - 业务逻辑 : moving from stored procedures to BRMS. 优缺点

Question

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

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

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

1. 他们的经验是，当前基于 PLSQL 的实现比在中间层(即 Java)实现逻辑的实现要高效得多。

   我们的用户通常确实需要我们的软件具有较短的响应时间，因为它还指导他们在工业环境中的操作。

2. 我们的团队不大，最了解业务规则的人也是实现存储过程的人。它们不习惯与 Java 一起工作，最重要的是，使用 PLSQL 使我们能够忽略有关框架、系统集成和不同层之间映射的所有麻烦。

   如果我们要切换到 PLSQL 以外的其他东西，它必须是不需要大量 Java 编码并且可能独立于框架的东西。

3. PLSQL 允许将应用程序的权重转移到昂贵的 DBMS 上。理想情况下，我们希望 BRMS 和 DBMS 之间能够有效集成。

为了更好地展示我的提案，我需要一些有关以下问题的客观数据:

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

我上网查了一下，找到了一些引用资料。不幸的是，他们中的大多数人将纯 Java 代码与存储过程或纯 Java 代码与 BRMS 的实现进行比较。我找不到任何比较存储过程和 BRMS 的内容，也找不到描述如何将存储过程解决方案与 BRMS 集成的内容。

非常感谢。

Answer 1

1. 如果您选择一个完善的引擎，则规则引擎的性能很可能会比访问数据库以检索和评估规则的系统的性能好得多。我们目前使用的引擎可以在大约 50 毫秒内根据单个复杂规则评估大约 200 万个对象。那是 200 万个复杂对象。

2. 引擎的功能之一应该是允许业务人员(而不是程序员)创建和管理其规则的 UI。有了适当的引擎，程序员永远不应该创建和管理规则。您可能正在查看开源引擎(Drools 等)，他们通常会忽略这一点。这就是为什么您会认为您的人员必须学习 Java 才能创建业务规则。这从一开始就是一个错误的假设。

3. 业务规则引擎的全部意义在于从主代码中抽象出业务逻辑。您的基于数据库的系统不提供普通 BRE 所提供的抽象级别。我不了解你的系统，但根据我对引擎和“数据库规则系统”的了解，我对此有 99.9% 的肯定。您需要一个数据库来存储规则。仅此而已。

4. 这取决于您选择的引擎。 IT 部门的培训通常很少，而业务部门的培训则处于中等水平。

希望这有帮助。