存儲過程的業務邏輯

Question

我正在使用存儲過程來訪問我的db數據。我試圖把業務邏輯放在代碼中，而不是放在存儲過程中。但我有一個案例，我不知道如何解決：

我有一個像表：Items(item_id, itemd_name, item_price)其中700項。

現在我想顯示客戶端的所有項目和他們的名字。 由於我爲網絡開發，我不想加載所有700個項目，但一次使用分頁 - 40個項目。當我寫「加載」時，我發現存儲過程返回數據表，並且我寫的代碼將每行轉換爲一個item類 - 這就是爲什麼我不想加載700個項目，它會處理很多數據我並不需要）

所以我寫了存儲過程，知道得到40項。

現在，我需要總結所有項目的價格，並將其加入16％的稅。

問題是我無法使用從商店過程中獲得的40件商品，因爲我需要總結所有700件商品的價格+稅。

我發現的唯一解決方案是使用另一個存儲過程，將返回價格+稅額總和。

Answer 1

基本上，您正在使用兩種不同的存儲過程，用於兩種不同（儘管連接）的業務需求，這在我的書中可以。

第一個是：顯示具有給定偏移量和頁面大小的數據頁面。 第二個是：根據一些規則顯示數據彙總。

如果您使用一個簡單的存儲過程來獲取所有數據，並且您可以在應用程序端處理分頁和總結，並且符合您的「數據庫中沒有邏輯」規則，則兩者都可以完成。當你有700行時，這不會成爲問題，但是，如果這個數字增加到幾十萬，那麼你將會在加載和處理大量你並不需要的項目時產生巨大的性能損失。

第二種方法是將分頁邏輯放在一個proc中，並在另一個邏輯中進行總結。分頁邏輯非常通用，所以它不必被認爲是「業務」，但爲了有用，彙總生成必須包含真實的業務邏輯。這將工作，表現明智，但顯然違反了你的規則。

當然，沒有一個正確的答案，但在大多數情況下，我並不介意將業務邏輯放入數據庫中，因爲即使數據庫的結構也受到系統業務規則的限制。如果我們絕對要「在數據庫中沒有業務規則」，我們應該放棄默認值，檢查約束等，因爲它們也是數據的業務限制，這些不是數據本身的屬性。