傳遞業務邏輯（c＃）來處理（sql）會提高性能嗎？

Question

我們正在研究一種算法，用於計算通過可變路線將資源從多點移動到點X的最佳方式，並且過程如下所示：

1）獲取所有可能的路線（DB命中以獲取所有路線參與溶液）

2）獲取所有可能的出發點

3）建立一個雙向圖中所有的路線相結合。

-----的foreach起點----

4）計算使用霍夫曼Pavley算法（第k最短路徑我們限制該一定數量路徑EI：第10個shortes路徑）

用於實際起點-----

5） - - - - 的foreach路徑評估路線計算多少資源瓦特e可以從每個路線節點運送到目的地

6）根據從每個點移動的資源數量和移動和轉運數量（將資源從一個運輸工具轉移到另一個運輸工具）分配一個標點符號可能的方案。

-----爲實際起點-----

----- END的foreach起點END的foreach路徑----

7）返回由標點符號排序的可能解決方案

該邏輯的第一個版本花費了大約1分鐘來計算解決方案。但是在第二次修訂中，我們發現我們有很多Select N + 1問題，所以我們優化了查詢（不是全部），現在每次運行需要3-10秒，具體取決於變量的數量。

但現在有人建議通過所有的邏輯來處理SQL，並讓SQL服務器處理所有的計算，他說，由於所有的數據已經在SQL Server上，數據庫將花費更少的時間來完成所有的計算避免了所有選擇N + 1和延遲加載問題。同時他也關心併發性，運行這個邏輯的多個用戶會關閉應用服務器，但他說sql-server可以很好地處理這種負載。

我的意見：也許我們應該在嘗試將1500行c＃邏輯傳遞給Transact SQL之前嘗試優化所有查詢。更不用說，對於某些計算，我們使用的是雙向圖和Hoffman Pavley算法的第三方庫，這些算法在交易中不可用，或者我們需要尋找其他已經在交易中編寫或者實現了所有這些邏輯的東西。

注意：我們使用Nhibernate作爲ORM。

Answer 1

移動邏輯SQL可以幫助，但它的成本：

• 維護SQL，做的是1500行C＃代碼做同樣的事情是真正的地獄（100線查詢，存儲過程成爲了過期增加新功能等）後
• 調試複雜得多

所以我的觀點是，你應該嘗試所有的邏輯遷移到數據庫之前優化查詢。

Answer 2

我只會考慮將邏輯移到數據庫作爲最後的手段。

• 一個很好的指導是保持數據庫中基於集合的處理，並在應用程序中迭代處理。你有很多的foreach語句，除非它們可以被拼湊成set操作，否則你真的會在數據庫世界受到影響。

• 如果這是業務規則的應用，那麼它應該在應用層中，除非有理由將其放入數據庫中。

• 將1500行代碼移植到TSQL代碼需要很長時間。如果它是最新版本的MSSQL，則可以使用.NET CLR，但根據我的經驗，Windows服務器上的.NET要明顯慢於.NET。

• 應該比較簡單地提前將所有必需的數據提取出來以避免N + 1選擇;得到的一切你需要並將它們全部加入到一個適當的對象圖中。

最後，似乎前4個步驟是針對所有請求進行復制的。選擇所有數據並處理前四個步驟然後將圖保存在內存中可能是有意義的，避免了對每個請求的檢索和預處理的顯着前期命中。這可能是不可能的，但會完全消除數據檢索問題。

Answer 3

這裏的交易：

邏輯轉移到數據庫常常會導致複雜的報告要求，如你更好的性能。這是通過更好地索引數據來完成的，這樣索引就意味着大部分工作（即：排序）在插入時完成。

由於排序工作是在插入時爲您需要的索引完成的，因此最終會導致較慢的插入和其他寫入操作。對於需要做的不僅僅是報告的系統而言，這往往是有害的。

此外，在某些時候，您會想要考慮應用程序的縮放比例。當你這樣做時，考慮你的數據庫服務器可能已經是你最昂貴的服務器，以及最昂貴的升級服務器。許可費用本身就會使升級數據庫服務器對預算管理人員不那麼可口。數據庫通常也很難在集羣中工作。與數據庫相比，添加Web或應用程序服務器並讓他們在農場工作是在公園散步。出於這些原因，您可以通過任何方式來釋放數據庫中的性能壓力，這可能會改進應用程序的擴展方式。

Answer 4

很難提供一個優化的問題是這樣的一般見解，但聲明：

「因爲所有數據已經​​是SQL服務器將花費更少的時間對數據庫做所有的計算上「

不一定是對的。如果你根本不改變邏輯，你的C＃代碼到t-sql的直接端口仍然會運行儘可能多的查詢。您將節省在SQL服務器和運行應用程序的計算機之間傳輸數據的時間，但這是瓶頸，還是S​​QL服務器實際運行所有這些查詢所花費的時間？每個查詢的結果有多大？

另一個問題是，t-sql是否可以更快地完成這裏涉及的所有計算，只要它們涉及遍歷表中的數據並使用該數據執行某些操作？我對此表示懷疑。根據實際處理的時間長短（而不是等待數據庫），它甚至可能會變慢。

底線是，它聽起來像翻譯它將是一個巨大的努力，如果你甚至遠程考慮這種方法，你應該做很多測試，以確定時間到了哪裏，看看你可以站在增益， 如果有什麼。