0

我们正在开发一个应用程序，它在 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 集成的任何东西。

非常感谢。

4

2 回答 2

1

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

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

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

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

希望这可以帮助。

于 2012-12-03T14:23:11.223 回答
1

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

我已经将它用于一些 ETL 任务，但没有任何需要高性能处理大容量数据的任务。如果您愿意为灵活性牺牲一些性能，但我建议您这样做。

http://docs.oracle.com/cd/B19306_01/appdev.102/b14288/toc.htm

于 2012-12-03T15:29:47.103 回答