業務邏輯到存儲過程 - 仍然困惑

我看了很多關於articles爲什麼我們不應該有幾個地方的業務邏輯，但儘量保持它在BLL代碼。我明白易於維護的重點，並且更清楚地瞭解代碼的功能。業務邏輯到存儲過程 - 仍然困惑

但是，我從來沒有發現申請（重複）的一些商業規則，存儲過程會顯著減少數據庫客戶端應用程序的數據傳輸時的情況下我們應該怎樣做任何解釋？

例如，我目前正在OS在一段較長時期的一些statiscal數據顯示。目前所有的商業邏輯/規則都在商業邏輯層（dll）中。用戶可以選擇在月份級別顯示一年的結果。這意味着，如果我不想在存儲過程中使用業務規則，則需要返回大約1,000,000條記錄，然後將業務規則應用於客戶端的這些記錄。但是，如果我是業務規則適用於存儲過程，那麼它會返回的記錄數量減少到12

應用業務規則的一個例子是這個樣子：

AVG(CASE WHEN Field1 IS NULL 
       THEN CASE WHEN c.Field2 = 1 
       THEN (cap1.Field3/cap1.Field4) * 60 
       ELSE CASE 
..... etc

所以不是一個簡單的邏輯，而是一個複雜的邏輯。由於這種邏輯可以在許多不同的存儲過程中重複使用，因此可以作爲數據庫中單獨函數的候選，以避免重複代碼。

那麼，什麼是推薦的方式嗎？而爲什麼？

來源

2014-05-21 Goran

也許你仍然可以有業務邏輯，它屬於這東西歸類爲多個「計算」？

無論哪種方式，你有一個令人信服的理由這樣做計算在數據庫層，當你在一百萬加行。所以我會繼續計算功能。所以，在你的例子可重複使用的功能將使用類似：

SELECT AVG(dbo.fnFieldsEvaluate(Field1, Field2, Field3, Field5)) as FieldAvgs, 
...

，或者如果它使用了很多，夠簡單，只在單個行依賴於列，表中的計算列會更方便。

CREATE TABLE dbo.Products 
    (Field1 ...., 
    Field2 ...., 
    RowEvaluatesTo AS CASE WHEN Field1 IS NULL 
       THEN CASE WHEN Field2 = 1 
       THEN(Field3/Field4) * 60 
       ELSE CASE ...

您的函數dbo.fnFieldsEvaluat（或計算列）將提供計算所在的一個位置。

來源

2014-05-21 01:31:54 JBrooks

業務邏輯到存儲過程 - 仍然困惑

回答

相關問題