DataTable的選擇VS LINQ選擇

Question

時DataTable.Select應在內存中的數據表打交道時使用與LINQ Select上有何建議？

我發現LINQ語法更簡單也更強大，但我不確定是否有性能或其他問題使DataTable選擇更可取。

（我使用的是第三方API，它提供的是已經從數據庫中預先填充的DataTable。我需要的是進一步篩選的內存。）

Answer 1

基於個人經驗，我儘量避免使用Datatable.Select。我覺得它很慢，有一些奇怪的錯誤。

我遇到的一個（由Microsoft確認並記​​錄在案的）bug是因爲DataTable.Select並不總是在語句中有括號時正確計算AND條件。

例如，（Col1> 1）AND（Col < 10）可能無法返回正確的答案，而Col1> 1 AND Col < 10將無法​​正常工作。

這個錯誤不會顯示在每臺計算機上。在我的情況下，我使用的支票在我的開發平臺和除一個之外的每臺客戶端計算機上運行良好。在發現這個錯誤後，我開始轉向使用LINQ進行選擇，並注意到操作速度顯着提高。

附註：不用長時間解釋，我的公司不使用數據庫來存儲數據。 我們使用DataTable的操作的所有都涉及從平面文件加載的內存表。所以我不是在談論LINQ 2 SQL，而是LINQ to Dataset。

Answer 2

嗯，你跟LINQ to SQL比較數據集？如果你是，那麼我會說只是溝數據集和L2S。 DataTable.Select假定您已經用數據填充了數據表。這可能會導致設計不佳，因爲您需要加載的數據超過您的需求，只能在客戶端進行過濾。讓SQL Server爲你查詢，並處理它給你的結果集。只有在迭代集合時，L2S纔會從數據庫中讀取數據，因此在之前創建查詢要容易得多。

LINQ to SQL引入了一些調試開銷，因爲從動態生成的SQL中取出動態生成的SQL可能很尷尬（而在數據集中，您首先提供了SQL），但在幾乎所有其他情況下，優雅。 deferred loading功能特別有用。

如果你不使用數據庫，那麼我仍然更喜歡數據集中的LINQ（在這種情況下特別稱爲LINQ to Objects）。語法就簡單多了，因爲沒有魔術字符串（即SQL語句），所以測試起來更容易，而且編譯時會出現拼寫錯誤等警告。

Answer 3

甚至沒有提到LINQ，我不會使用DataTable。除非我絕對必須選擇，因爲在大多數情況下，這意味着在客戶端執行應該可能在數據庫中執行的操作。

更新：我在這裏的答案可能有點誇大了。有是有時合法的理由使用DataTable作爲（希望）小的內存數據庫，最大限度地減少客戶端到數據庫的往返行程。