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 和類似工具時有過糟糕的經歷。 我不推薦用於簡單的用例。