2008-12-09 14 views
6

Todo,LINQ-to-SQL CompiledQuery.Compile() con Actualizar, Eliminar, Insertar?

Así que tengo todas mis consultas de selección en LINQ-to-SQL convertidas a CompiledQueries para acelerar las cosas. Funciona muy bien hasta ahora para declaraciones seleccionadas, pero no he podido averiguar cómo precompilar las instrucciones de inserción, actualización o eliminación.

Otorgado, cuando inserte, elimine o actualice en LINQ-to-SQL, debe usar el modelo de objetos. Pero, obviamente, en algún punto del camino genera una consulta, que sería bueno precompilar y almacenar en un miembro estático.

¿Esto es posible? ¿Cómo es el rendimiento de LINQ para actualizaciones, eliminaciones e inserciones cuando no está precompilado? Pude ver que era mucho más rápido que los seleccionados, porque lo que hacen debajo es mucho más simple y menos "dinámico" ...

Respuesta

8

Hay una gran diferencia. Las consultas de selección de Linq-To-SQL pueden ser grandes árboles de expresiones complejas. Es esto lo que puede llevar algún tiempo 'compilar'. En este caso, se fusiona con algún T-SQL que se puede ejecutar contra un servidor SQL. Por lo tanto, tiene sentido guardar en la memoria caché el resultado de una operación para que pueda volver a utilizarse.

Sin embargo, otras tareas como Eliminar, Actualizar e Insertar son operaciones simples que no requieren la conversión de un árbol de expresiones a T-SQL (LINQ en sí mismo trata sobre la consulta). Es lamentable que hayamos sido entrenados para pensar en el código SQL que realiza estas otras operaciones como 'consultas', no estamos pidiendo realmente ninguna información.

Estas operaciones solo están definidas por el DataContext no por LINQ, por lo que el código para realizar estas funciones ya está compilado.

+0

Genial. Tiene sentido. Supongo que estaba olvidando que en LINQ-to-SQL las consultas Actualizar y Eliminar nunca tendrán cláusulas WHERE complejas. Siempre solo actualizan/eliminan en función de una identificación. Y los insertos en LINQ-to-SQL probablemente nunca tengan ninguna cláusula WHERE ... –

3

Creo que las tres únicas inserciones tendrían sentido para poder compilar y reutilizar porque eliminar es trivialmente simple (ELIMINAR DE LA TABLA DONDE LA CLAVE ...) y ACTUALIZAR solo actualiza los campos que han cambiado y así varía por operación de actualización.

[) amien

+0

Interesante - Creo que parte de mi pensamiento fue que la Actualización y las Eliminaciones podrían ser más complejas. En SQL estándar, sin duda podrían serlo: podría tener alguna declaración WHERE compleja compleja al final de una Actualización o Supresión. Pero en LINQ-to-SQL solo usaría la clave principal o el estado actualizado. –

0

L2S utiliza "Sp_executesql" por lo que después de ejecutar la primera vez que estará en la caché del plan de ejecución del procedimiento almacenado. Las ejecuciones posteriores (de la misma consulta, no los mismos params) reutilizarán el plan compilado de la memoria caché. Entonces, lo que está pidiendo se maneja automágicamente por SQL Server 'detrás de escena'.

+0

Verdadero - en términos del plan de ejecución. La "precompilación" de la que estoy hablando es la parte donde se analiza el LINQ desde su árbol de expresiones en SQL. Vea el método CompiledQuery.Compile(). –

Cuestiones relacionadas