LINQ-to-SQL CompiledQuery.Compile () avec Update, Delete, Insert?

Question

Tous,

J'ai donc converti toutes mes requêtes sélectionnées dans LINQ-to-SQL en utilisant CompiledQueries pour accélérer les choses. Fonctionne très bien jusqu'à présent pour certaines instructions, mais je n'ai pas été en mesure de compiler à l'avance les instructions d'insertion, de mise à jour ou de suppression.

Bien entendu, lors de l'insertion, de la suppression ou de la mise à jour dans LINQ-to-SQL, vous devez utiliser le modèle d'objet. Mais il est évident qu’à un moment donné, il génère une requête, ce qui serait bien de précompiler et de stocker dans un membre statique.

Est-ce possible? Quelles sont les performances de LINQ comme pour les mises à jour, les suppressions et les insertions quand elles ne sont pas précompilées? Je pouvais le voir être beaucoup plus rapide que les sélections, parce que ce qu’elles font en dessous est beaucoup plus simple et moins & "Dynamique &"; ...

Answer 1

Il y a une grande différence. Les requêtes de sélection Linq-To-SQL peuvent être de grands arbres d'expressions complexes. Celles-ci peuvent parfois nécessiter une «compilation». Dans ce cas, fusionnant avec certains T-SQL pouvant être exécutés sur un serveur SQL. Il est donc logique de mettre en cache le résultat d’une opération pour pouvoir la réutiliser.

Cependant, les autres opérations de suppression, de mise à jour et d’insertion sont des opérations simples ne nécessitant pas la conversion d’une arborescence d’expressions en T-SQL (LINQ est lui-même une question d’interrogation). Il est regrettable que nous ayons été formés à considérer le code SQL qui exécute ces autres opérations comme des "requêtes". Nous ne demandons donc aucune information.

Ces opérations ne sont définies que par le DataContext et non par LINQ. Par conséquent, le code pour exécuter ces fonctions est déjà compilé.

Answer 2

Je pense que les trois seules insertions auraient du sens pour pouvoir compiler et réutiliser car supprimer est trivialement simple (DELETE FROM Table WHERE Key ...) et UPDATE ne met à jour que les champs qui ont changé et varient opération de mise à jour.

[) amien

Answer 3

L2S utilise " sp_executeSQL " ainsi, après que vous l'ayez exécuté pour la première fois, il sera dans le cache du plan d'exécution de la procédure stockée. Les exécutions ultérieures (de la même requête - pas les mêmes paramètres) vont réutiliser le plan compilé à partir du cache. Ainsi, ce que vous demandez est géré automatiquement par SQL Server "en coulisses".