DataTable Seleccionar vs LINQ Seleccionar

Question

Cualquier consejos sobre cuándo DataTable.Select deben utilizarse frente LINQ Select cuando se trata de un DataTable en memoria?

La sintaxis de LINQ es más fácil y más potente, pero no estoy seguro si hay problemas de rendimiento u otros que hacen preferible una selección de DataTable.

(estoy usando un tercer API proveedor que proporcione una DataTable que ha sido pre-pobladas de la base de datos. Necesito filtrar aún más que en la memoria.)

Answer 1

Basado en la experiencia personal, trato de evitar el Datatable.Select. Me parece que es lento y tiene algunos errores extraños.

Un error (confirmado y documentado por Microsoft) con el que me encontré fue que DataTable.Select no siempre evalúa AND correctamente cuando hay paréntesis en la instrucción.

Por ejemplo, (Col1> 1) y (Col < 10) se puede dejar de devolver respuestas correctas, mientras que Col1> 1 y Col < 10 funcionará correctamente.

Este error no aparece en todas las computadoras. En mi caso, el cheque que estaba usando funcionaba bien en mi plataforma de desarrollo y en cada computadora cliente excepto una. Después de descubrir este error, comencé a usar LINQ para seleccionar y noté un aumento significativo en la velocidad de las operaciones.

Nota al margen: sin entrar en explicaciones largas, mi empresa no usa una base de datos para almacenar datos. Todas las de nuestras operaciones con DataTables involucran a las tablas de memoria cargadas desde archivos planos.Así que no estoy hablando de LINQ 2 SQL, sino de LINQ to Dataset.

Answer 2

Hmm, estás comparando conjuntos de datos con LINQ to SQL ? Si es así, entonces diría que simplemente elimine los conjuntos de datos y vaya con L2S. DataTable.Select supone que ya ha llenado la tabla de datos con datos. Esto puede llevar a diseños defectuosos en los que carga más datos de los que necesita, solo para filtrar en el cliente. Haga que SQL Server haga su consulta por usted y trabaje en el conjunto de resultados que le brinda. L2S leerá de la base de datos solo cuando itere la colección, por lo que es mucho más fácil formular sus consultas antes de presionando la base de datos.

LINQ to SQL introduce cierta sobrecarga de depuración porque puede ser incómodo obtener el SQL generado dinámicamente (mientras que en los conjuntos de datos se está suministrando el SQL en primer lugar), pero en casi todas las demás situaciones es mucho más elegante. La funcionalidad deferred loading es especialmente útil.

Si no está trabajando con una base de datos, aún así preferiría LINQ (específicamente conocido como LINQ to Objects en este escenario) sobre conjuntos de datos. La sintaxis es mucho más fácil y, como no hay cadenas mágicas (es decir, declaraciones SQL), es más fácil de probar y obtienes advertencias en tiempo de compilación para errores tipográficos, etc.

Answer 3

Sin siquiera mencionar LINQ, no utilizaría DataTable. Seleccione en cualquier parte a menos que sea absolutamente necesario, ya que en la mayoría de los casos significa realizar en el cliente algo que probablemente debería realizarse en la base de datos.

Actualización: mi respuesta aquí es probablemente un poco exagerada. Hay son razones a veces legítimas para usar una DataTable como una (pequeña) base de datos en memoria que minimiza los viajes de ida y vuelta del cliente a la base de datos.