我有一個ADO.NET/TSQL性能問題。我們在我們的應用程序兩個選項：一個大的調用與多個較小的TSQL調用
1）一個大的數據庫調用與多個結果集，然後通過每個代碼一步結果集，並填充我的對象。這導致數據庫的一次往返。
2）多個小型數據庫調用。
還有更多的代碼重用與選項2是該選項的優點。但我想就性能成本問題得到一些意見。兩次小型往返程序的速度是往返數據庫一次的兩倍，還是僅僅是一小步，例如10％的性能損失？我們使用存儲過程和ADO.NET使用C＃3.5和Sql Server 2008。
我認爲這部分取決於你何時需要這些數據。例如，如果您在一個大型流程中返回十個數據集，並立即查看屏幕上的所有十個數據集，那就去做吧。但是，如果您返回十個數據集，並且用戶只能通過點擊頁面查看其中三個數據集，則發送其他數據庫會浪費服務器和網絡資源。如果您返回十個數據集，但用戶確實需要在對第5和第6組進行更改後才能看到第7和第8組數據，那麼如果過早返回，用戶會看到錯誤的信息。
如果您對一個主存儲過程中調用的每個數據集使用單獨的存儲過程，那麼根本沒有理由不能在其他地方重用代碼，因此代碼重用在我看來並不是真正的問題。
如果您對性能感興趣，請嘗試對兩者進行測試，看看哪個性能更好。
個人而言，我更喜歡第二種方法。它使開發人員的生活更輕鬆，使代碼更易於重用，並且模塊化了事物，因此更容易進行更改。
就我個人而言，我會去一個更大的往返。
這一定會通過調用代碼的可重用性確切的影響，以及它會如何進行重構。
但是如前所述，這將取決於你的具體情況，在維護VS性能可能是一個因素。
我個人很喜歡你說的原因選項二：代碼重用
但考慮這一點：對於小請求的延遲可能比你的要求做什麼更長。你必須找到適當的平衡。
不要優化性能，直到需要這樣做。這意味着你應該分析你的預期使用模式，並確定這個過程的典型使用頻率，以及當前設計產生的用戶界面延遲。如果用戶從應用程序收到反饋的時間少於幾（2-3）秒，並且來自此進程的應用程序負載不是服務器容量的過度負載，那麼請不要擔心。如果用戶正在等待一段不可接受的響應時間（受限但不可測量）或者服務器過載，那麼是時候開始優化了。那麼，哪種優化技術最有意義，或者成本效益最高，取決於你對問題的分析告訴你什麼。
因此，在此期間，關注可維護性。這意味着，在你的情況下，代碼重用
隨着ADO.Net開發者，你的工作就是讓代碼正確，清晰，維護越好。這意味着你必須分開你的顧慮。
SQL Server連接技術的工作使其變得更快。
如果您實施了一個正確的，清晰的，可維護的應用程序來解決業務問題，並且事實證明數據庫訪問是防止系統在可接受的限制內運行的主要瓶頸，那麼，只有這樣，如果您開始尋找解決問題的方法。這可能包括也可能不包括整合數據庫查詢。
這聽起來有點顯而易見，但只能在一個電話中發送你需要的東西。
例如，我們有一個「getStuff」存儲過程用於演示。 「updateStuff」proc調用「getStuff」過程，「updateStuff」的客戶端包裝方法需要輸入「Thing」。所以一次往返。
Chatty服務器是一件你可以用最少的努力預防的事情。然後，您可以根據需要調整數據庫或客戶端代碼......但無論代碼運行得有多快，都很難將往返分解出來。在極端情況下，如果您的Web服務器與您的數據庫服務器位於不同的國家/地區，該怎麼辦？
編輯：這是值得注意的SQL傢伙（HLGEM，astander，我）說：「一週之旅」和客戶端的傢伙說：「多，代碼重用」 ......
我這個問題我自己掙扎。我還沒有答案，但我確實有一些想法。
回顧了他人給出的答案後，還有第三種選擇。
在我的應用程序中，大約十或十二個調用服務器來獲取我需要的數據。一些數據字段是varchar max和varbinary max字段（圖片，大文檔，視頻和聲音文件）。我所有的呼叫都是同步的 - 即在請求數據時，用戶（和客戶端程序）別無選擇，只能等待。他可能只想閱讀或查看只有在所有時候纔有意義的數據，而不僅僅是部分存在。我相信，這個過程比較慢，我正在開發一種替代方法，該方法基於從DLL libaray向服務器異步調用，該方法向客戶端發送事件以向客戶端宣告進度。客戶端被編程爲處理DLL事件，並在客戶端設置一個變量，指示Chich調用已完成。然後，客戶端程序可以做它必須做的事情，以準備在＃1調用中接收的數據，同時DLL正在異步進行以獲取調用＃2的數據。當客戶端準備好處理呼叫＃2的數據時，它必須檢查狀態，並在必要時等待進行（我希望這將是一個短暫的或根本沒有等待）。通過這種方式，服務器端和客戶端軟件都能以更高效的方式完成工作。
您是否設置了連接池？ – 2010-03-23 15:28:33