業務邏輯：從存儲過程轉移到BRMS。優點和缺點

Question

我們正在開發一個應用程序，該應用程序在Oracle數據庫的存儲過程中實現了業務邏輯。幾年來一直如此。 商業規則是多種多樣的，並經常爲特定客戶定製。

目前它們有些與數據管理和數據檢索代碼混合在一起。 我一直在考慮提出移動BRMS中的一些邏輯。

我的同事們很可能會反對因爲：

1. 他們經歷了基於PLSQL當前實現顯然比中間層，即在Java中實現一個具有邏輯更有效。

   我們的用戶通常確實需要從我們的軟件得到的短響應時間，因爲它也指導他們在工業環境中的操作。

2. 我們的團隊不大，對業務規則最瞭解的人也是實施存儲過程的人。他們不習慣使用Java，最重要的是，使用PLSQL可以讓我們忽略關於框架，系統集成和不同層之間映射的所有問題。

   如果我們要切換到PLSQL以外的其他東西，它必須是一些不需要很多java編碼並且可能與框架無關的東西。

3. PLSQL允許將應用程序的權重用於昂貴的DBMS。理想情況下，我們希望在BRMS和DBMS之間進行有效的整合。

更好地展現我的建議我需要對以下問題的一些客觀數字：

1. 從存儲proecdures移動到BRMS的性能損失
DBMS和BRMS之間
2. 集成
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來說，培訓通常是最小的，並且對於業務來說有點中等水平

希望這會有所幫助。

Answer 2

Oracle有一個內置的規則引擎，這個引擎並沒有被廣泛宣傳。但是它是用PL/SQL構建的，當然它的接口是PL/SQL。

我已經將它用於一些ETL任務，但沒有要求批量數據的高性能。如果你願意犧牲一些靈活性的表現，但我會推薦它。

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