DataTable Select vs LINQ Select

Question

在处理内存中的DataTable时，是否应该使用 DataTable.Select 与 LINQ Select 的建议？

我发现LINQ语法更简单，更强大，但我不确定是否存在性能或其他问题使得DataTable选择更合适。

（我正在使用第三方API，它提供了一个已从数据库中预先填充的DataTable。我需要在内存中进一步过滤。）

Answer 1

根据个人经验，我尽量避免使用Datatable.Select。我发现它很慢并且有一些奇怪的错误。

我遇到的一个（由Microsoft确认并记​​录）的错误是，当语句中有括号时，DataTable.Select并不总是正确评估AND条件。

例如，（Col1＆gt; 1）AND（Col＆lt; 10）无法返回正确的答案， 而Col1> 1和Col＆lt; 10将正常工作。

此错误未显示在每台计算机上。在我的情况下，我使用的检查在我的开发平台和每个客户端计算机上运行正常，除了一个。在我发现这个错误后，我开始转向使用LINQ进行选择，并注意到操作速度的显着提高。

旁注：不做长解释，我的公司不使用数据库来存储数据。 我们使用DataTables的所有操作都涉及从平面文件加载的内存表。所以我不是在谈论LINQ 2 SQL，而是LINQ to Dataset。

Answer 2

除非提到LINQ，否则我不会使用DataTable.Select 任何地方，除非我绝对不得不这样做，因为在大多数情况下，这意味着在客户端执行应该在数据库中执行的操作。< / p>

更新：我的回答可能有点夸大其词。 有时是合法的理由将DataTable用作（希望）小型内存数据库，最大限度地减少客户端到数据库的往返次数。

Answer 3

嗯，你在用LINQ to SQL比较数据集吗？如果你是，那么我会说只是沟渠数据集和L2S。 DataTable.Select假设您已经使用数据填充了数据表。这可能导致设计错误，您加载的数据超出了您的需求，只需在客户端进行过滤即可。让SQL Server为您进行查询，并处理它为您提供的结果集。只有在您对集合进行迭代时，L2S才会从数据库中读取数据，因此在强化数据库之前更容易制定查询。

LINQ to SQL引入了一些调试开销，因为从中获取动态生成的SQL可能很难（而在数据集中，您首先提供SQL），但在几乎所有其他情况下，它更优雅。 deferred loading功能特别有用。

如果您不使用数据库，那么我仍然更喜欢LINQ（在此方案中特别称为LINQ to Objects）而不是数据集。语法更容易，并且因为没有魔术字符串（即SQL语句），所以它更容易测试，并且您会收到错别字的编译时警告等。