我有一個Winform應用程序，將在美國和中國使用。 SQL Server 2005數據庫位於美國，因此中國人的數據訪問速度將會變慢。我決定使用DataReader和Dataset來獲得最佳性能。數據將在檢索時立即加載到業務對象中。Winform中的數據庫或數據集與數據庫的長途旅行？
問題：哪個執行得更好（DataReader/DataSet）從遠離的數據庫中提取數據？我已經讀過DataReader會返回到每個.Read（）的數據庫，所以如果連接起步緩慢，那麼DataSet會是更好的選擇嗎？
謝謝
如果您期待長距離/慢速鏈接，則數據傳送者與數據集的性能相比於數據庫往返速度幾乎不可測量。
雖然DataSets可能會使用更多的內存，但如果您要處理很多的數據，這可能是一個問題。
作爲一個參考點，您可以對「很多」數據進行粗略估計嗎？在我的工作中，結果集中有100,000個記錄是常見的。 – 2009-11-24 04:56:18
我們正在處理類似的，高達3-400k，到目前爲止沒有任何問題。 – nos 2009-11-25 08:55:33
取決於數據量。您不能在內存（數據集）中存儲太多數量。
兩個在我的腦海裏你的問題的方式：
- 並行化（System.Thread）
- backgroundworkers
首先可以提高LINQ to SQL的情況下的表現。第二個可以幫助最終用戶獲得更好的體驗（非流暢的UI）。
我覺得沒關係因爲連接是瓶頸。
兩者都使用相同的機制來獲取數據（ADO.NET /數據庫）。
如果你能做到這一點，你可能會壓縮服務器上的查詢結果然後發送給客戶端。這會提高性能。
取決於它是什麼數據庫。不好的情況，如果它是訪問。
取決於有多少數據移動，使用方式是什麼？來自中國的用戶是否會閱讀或寫入常見數據？他們是否需要查看所有數據？
這個想法是，分開數據（如果它有助於場景）並將其合併回來。
自DataSet使用DataReader填充以來選擇哪個並不重要。儘量避免通過緩存結果或獲取額外數據來儘可能調用分貝。一些獲得額外數據的調用可能會勝過桌面上的許多小啄食。也許BackgroundWorker可以預先加載一些你知道你將會使用的數據。
僅供其他讀者使用：DataReader的性能更高。顯然，這些用戶並沒有嘗試使用這兩種方法，而是實際測試了這些差異。用DataReader加載1,000條記錄，用DataSet加載1,000條記錄。然後嘗試將DataSet的記錄限制爲10條記錄（使用適配器的Fill方法，以便加載1,000條，但只有10條被填充/填充到DataSet中）。
我真的不知道爲什麼DataSets在填充操作過程中表現不佳，但差別很大。創建自己的集合並使用DataReader填充它們比使用非常臃腫且速度慢的DataSet要快得多。
您還沒有指定數據庫。你可以添加併爲其添加標籤嗎？ – shahkalpesh 2009-07-26 07:21:58