存儲過程與中間層的業務邏輯

Question

我想使用Postgres作爲web api存儲後端。我當然需要（至少一些）粘合代碼來實現我的REST接口（和/或WebSocket）。我想兩個選項：在使用非常薄的中間層來處理REST/WebSocket的一部分

1. 大部分業務邏輯的實現存儲過程，PL/SQL。

2. 中間層實現了大部分業務邏輯，並通過它的抽象數據庫接口到達Pg。

我的問題是什麼是上述設計的相互比較有關的靈活性，可擴展性，可維護性和可用性可能帶來的好處/障礙？我真的不關心確切的中間層實現（它可以是php，node.js，python或其他），我對實際建築設計選擇的好處和缺陷感興趣。

我知道我選擇（1）會失去一些靈活性，因爲將系統移植到其他oracle可能很困難，並且我的用戶將被綁定到postgres。在我看來，這並不重要，數據庫無論如何都是系統的一個組成部分。

我特別感興趣的是在選擇（2）的情況下丟失的好處，以及這兩種情況可能存在的缺陷。

Answer 1

我認爲這兩個選項都有其優點和缺點。 （2）方法好，而且已知。大多數簡單的應用程序和Web服務正在使用它。但有時候，使用存儲過程比（2）好得多。 下面是一些例子，恕我直言，是良好的存儲過程來實現：行

• 跟蹤更改。也就是說，您有一些包含定期更新項目的表格，並且您希望有另一個包含每個項目更改和日期更改的表格。

• 自定義算法，如果您的函數可以用作索引數據的表達式。

• 你想在幾個微服務之間共享一些邏輯。如果每種微服務都使用不同的語言來實現，則必須爲每種語言和微服務重新實現業務邏輯的某些部分。使用存儲過程顯然可以幫助避免這種情況。

（2）方法一些好處（有一些當然「但是」來迷惑你：d）：

• 您可以使用自己喜歡的編程語言來編寫業務邏輯。 但是：在（1）方法中，您可以使用您最喜歡的語言使用pl/v8或pl/php或pl/python或pl /任何擴展名編寫過程。

• 主要代碼比維護存儲過程更容易。 但是：有一些很好的方法可以避免代碼維護帶來的麻煩。即：遷移，這對每種方法都是一件好事。 另外，你可以把你的函數放到你自己的命名空間中，所以要重新安裝重新部署過程到數據庫中，你必須刪除並重新創建這個命名空間，而不是每個函數。這可以用簡單的腳本完成。

• 您可以使用各種ORM來查詢數據並獲取可能具有更復雜的邏輯和繼承邏輯的抽象層。在（1）中很難使用OOP模式。 我認爲這是針對（1）方法的最有力的論據，我不能在此添加任何'但是'。