Drools 引擎和数据库的区别

Question

我正在浏览 Drools 文档，发现它没有做任何有趣的事情/解决任何问题（可能是我错了）。

在 drools 中，我们将业务规则（在 .drl 文件中）指定为，例如，

  when "type = jewellery" then setDiscount(25%)
  when "type = KidDress" then setDiscount(30%) 

1. 以上与使用数据库有什么区别？

2. 我总是可以公开自定义 API，从中可以指定业务规则，我可以直接将它存储在 RDBMS 中。 如果需要，我可以正式构建一个示例 UI（在 1-2 天内），它与公开的 API 集成。 如果我公开 CRUD 操作，这也将允许业务人员轻松添加/更新/删除规则。

对于我解释的这么简单的事情，Drools 解决了什么问题？ 我在 g-search / 官方文档中找不到任何文档。

有人可以在这里帮忙吗？

Answer 1

与 Karol 的回答相反，我也使用了 Drools，但我对它们有很好的体验。 文档中的用例是有意简化的，但 Drools 还可以比数据库更有效地处理更复杂的用例。 我知道这是一个事实，因为我使用约 140 万条规则维护的服务已转换为使用数据库（使用您提供的相同参数）。 从平均 30-100 毫秒响应查询，到需要 750 毫秒到 2 多分钟才能响应（我不知道要多长时间，因为我们在 2 分钟后就超时了查询。）

这样做的原因是 Drools 允许我们实现“跌倒”逻辑。 在这种情况下，我的 140 万条规则用于确定住院患者是否需要其保险授权才能在医院完成手术。 规则范围从非常普遍到非常具体； 如果两个规则匹配输入数据，我们倾向于更具体的规则。 如果特定医院或医院+保险组合具有自定义规则，则应用特殊用例。 我们传递了我们所知道的关于患者的所有数据、他们的整个病史以及大量关于他们的保险的信息，然后规则决定了答案。

想象一下这个有意简化的场景：

rule "Car"
when
  Car() // very simple, I have a car
then
  setPrice(100)
end

rule "Red Car"
when
  Car( color == "red" ) // I have a red car
then
  setPrice(75)
end

rule "4-door Car"
when
  Car( doors == 4 ) // I have a 4-door car
then
  setPrice(200)
end

rule "Red Sedan"
when
  Car( color == "red", model == "sedan") // I have a red sedan
then
  setPrice(500)
end

rule "Blue 4-Door Discount"
when
  Car( doors == 4, color == "blue") // I have a blue 4-door car
then
  setPrice(150)
end

现在我们开始玩不同配置的 Car。 黄色车，2门跑车只匹配第一条规则，价格为100。红色四门车匹配两条​​规则； 价格是75还是200？ 取决于您如何编写规则以及“设定价格”的作用； 可能在我在这里写的规则中价格是 200。一辆蓝色轿车？ 100. 等等。

如果我们将其转换为一个数据库表（为简单起见，单个表 Car 包含“color”、“model”和“doors”列），该查询会是什么样的？ （我实际上不知道我没有设法编写足够的查询；我也不是 DBA。）

我可以想出一整套示例，其中基于数据库的解决方案性能较差，或者根本不推荐。 例如，我曾经使用规则实现了一个 psuedo-BFS 算法，以找出从任意硬件配置到最新支持配置的最佳升级路径。 （每个版本只能升级到不同的其他版本，所以我们需要找出从给定版本到目标版本的最快路径，如果可能的话。）这可以在数据库中完成吗？ 可能，但这不是关系数据库所擅长的。 代码呢？ 当然，但现在您必须管理代码中可以升级到什么的列表。

对于极其简单的规则集，其中每个规则都是完全排他的并涵盖所有用例？ 当然，数据库的性能可能更高。 然而，现实世界的情况要么需要过于复杂的查询，要么可能根本不合适。

还有决策表？ 不惜一切代价避免它们。 它们加载缓慢，执行缓慢，占用的内存比它们需要的多，如果尝试大规模使用它们，您会遇到未记录的限制，并且调试它们很痛苦。

Answer 2

主要的两点：

1. 理论上，Drools 规则的编写方式可以让业务分析师等非技术人员更容易理解。

2. 如果决策逻辑存储在一个地方，例如作为决策表，它可能更容易管理。 如果您有一个更复杂的计算，其中包含许多变量（如信用检查标准），这有时会很方便。

实际上，在我使用 Drools 处理的所有项目中，开发人员必须编写从 DRL 文件调用的自定义函数来处理更复杂的逻辑。 这否定了上述好处并使解决方案更难管理，因为逻辑在普通代码和 DRL 文件之间共享。

我在使用 Drools 和类似工具时有过糟糕的经历。 我不推荐用于简单的用例。