Выбор таблицы данных против выбора LINQ

Question

Любой совет о том, когда DataTable.Select следует использовать против LINQ Select при работе с таблицей данных в памяти?

Я считаю, что синтаксис LINQ проще и мощнее, но я не уверен, есть ли проблемы с производительностью или другие проблемы, которые делают выбор DataTable предпочтительным.

(Я использую сторонний API, который предоставляет DataTable, который был предварительно заполнен из базы данных. Мне нужно отфильтровать эту дополнительную информацию в памяти.)

Answer 1

Исходя из личного опыта, я стараюсь избегать Datatable.Select. Я нахожу это медленным и имеет некоторые странные ошибки.

Одна (подтвержденная и задокументированная Microsoft) ошибка, с которой я столкнулся, заключалась в том, что DataTable.Select не всегда правильно оценивает условия AND, когда в операторе есть скобки.

Например, (Col1> 1) AND (Col <10) может не вернуть правильные ответы, тогда как Col1> 1 И Col <10 будут работать правильно. </p>

Эта ошибка появляется не на каждом компьютере. В моем случае проверка, которую я использовал, работала нормально на моей платформе разработки и на каждом клиентском компьютере, кроме одного. После того, как я обнаружил эту ошибку, я начал переходить на использование LINQ для выбора и заметил значительное увеличение скорости операций.

Примечание: без подробных объяснений моя компания не использует базу данных для хранения данных. Все наших операций с DataTables связаны с таблицами памяти, загруженными из плоских файлов. Так что я говорю не о LINQ 2 SQL, а о LINQ to Dataset.

Answer 2

Даже не упоминая LINQ, я бы не стал использовать DataTable.Select в любом месте , если бы мне это не было абсолютно необходимо, поскольку в большинстве случаев это означает выполнение на клиенте того, что, вероятно, должно выполняться в базе данных. *

Обновление : мой ответ здесь, вероятно, немного завышен. есть иногда законные причины для использования DataTable в качестве (надеюсь) небольшой базы данных в памяти, которая минимизирует циклические переходы между клиентом и базой данных.

Answer 3

Хм, вы сравниваете наборы данных с LINQ to SQL ? Если да, то я бы сказал, просто наборы данных ditch и перейти с L2S. DataTable.Select предполагает, что вы уже заполнили данные данными. Это может привести к плохим проектам, когда вы загружаете больше данных, чем вам нужно, только для фильтрации в клиенте. Получить SQL Server, чтобы сделать ваш запрос для вас, и работать с набором результатов, который он дает вам. L2S будет читать из базы данных, только когда вы выполняете итерацию коллекции, поэтому гораздо проще сформулировать ваши запросы , прежде чем попадет в базу данных.

LINQ to SQL вводит некоторые накладные расходы на отладку, потому что может быть неудобно извлекать из него динамически генерируемый SQL (тогда как в наборах данных вы предоставляете SQL в первую очередь), но почти во всех других ситуациях это гораздо более элегантно , Функциональность отложенной загрузки особенно полезна.

Если вы не работаете с базой данных, то я бы все же предпочел LINQ (в этом сценарии он известен как LINQ to Objects ) вместо наборов данных. Синтаксис намного проще, и поскольку нет никаких волшебных строк (то есть операторов SQL), его проще тестировать, и вы получаете предупреждения во время компиляции для опечаток и т. Д.