Linq no-noes: ¿el catch all sql-like select?

Question

Una de las cosas que le ha ganado como desarrollador junior es que nunca, nunca, hace un "SELECCIONAR *" en un conjunto de datos, ya que no es confiable por varias razones.

Desde que me mudé a Linq (primero Linq a SQL y luego Entity Framework), me he preguntado si el equivalente de Linq es igualmente desaprobado.

Ej

var MyResult = from t in DataContext.MyEntity 
       where t.Country == 7 
       select t; 

debemos estar seleccionando a un tipo anónimo con sólo los campos que queremos que menciona explícitamente, o es la captura all select ahora aceptable para LinqToSql y otros debido a la materia adicional que rodea a los datos que ¿proporcionar?

Regards

Moo

Answer 1

No está mal visto, está determinado por su caso de uso. Si desea actualizar el resultado y conservarlo, debe seleccionar t; sin embargo, si no desea hacerlo y solo está consultando para visualizarlo, puede hacerlo más eficiente seleccionando las propiedades que desee:

var MyResult = from t in DataContext.MyEntity 
       where t.Country == 7 
       select new { t.Prop1, t.Prop2 }; 

Esto es por algunas razones. La población de tipo anónimo es un poco más rápida, pero lo más importante es disables change tracking ... porque no puede persistir un tipo anónimo, no es necesario realizar un seguimiento de los cambios.

Here's an excellent rundown of the common performance areas like this eso es genial al comenzar. Incluye una explicación más detallada del seguimiento del cambio que acabo de describir también.

Answer 2

select t en este caso s seleccionar todos los campos de un tipo conocido. Está fuertemente tipado y menos sujeto a los mismos errores encontrados en SQL.

Por ejemplo en SQL

INSERT INTO aTable 
SELECT * FROM AnotehrTable 

podría fallar si AnotherTable cambiado, sin embargo, en LINQ/.Net no aparece esta situación.

Si está uniendo varias tablas, entonces no puede hacer un select * en Linq, tendría que crear un tipo anónimo con todos los tipos contenidos dentro.

Answer 3

Yo diría que lo que está haciendo es el equivalente a una declaración SELECT *. Es mejor devolver solo los campos que necesita, p.

var myResult = from t in DataContext.MyEntity 
       where t.Country == 7 
       select new T 
       { 
        Field1 = t.Field1, 
        Field2 = t.Field2 
       } 

Answer 4

Aún debe indicar explícitamente lo que desea seleccionar. Si seleccionas todo, aún estás obteniendo muchos más datos de los que necesitas y, a medida que se agregan cosas nuevas, también los extraerás innecesariamente. En general, una mejor práctica es extraer solo lo que necesita.

Answer 5

El uso de LINQ no aliviará el rendimiento al obtener campos adicionales.

Sin embargo, es imposible para generar un SELECT * FROM ... usando LINQ to SQL. Su código generará una declaración SELECT que nombra explícitamente todas las columnas definidas en su modelo; ignorará cualquier cambio en la base de datos.

Sin embargo, el rendimiento sigue siendo una preocupación, por lo que debe utilizar un tipo anónimo si solo está utilizando algunas de las columnas.

Answer 6

Puede ser necesario hacerlo como en el ejemplo, especialmente si lo que se necesita hacer es un cambio en la (s) fila (s).

en SQL select * es diferente de linq porque linq siempre devolverá el mismo número de columnas (como se define en el dbml).

Answer 7

La razón para evitar SELECT * es que la base de datos subyacente podría cambiar y, por lo tanto, los pedidos de columna podrían cambiar, lo que podría provocar errores en la capa de acceso a los datos.

No está realizando un SELECCIONAR * de su base de datos, solo está diciendo que quiere "t" y todo lo que conlleva. No hay nada de malo en eso si eso es realmente lo que necesitas.