Quoi de plus efficace avec des jointures et des sélections multiples fonctionnant avec LINQ?

Question

J'ai quelques requêtes complexes avec LINQ qui dans les coulisses font environ 7-9 jointures. Je suis en train d'optimiser la queries.Now Je suis un peu confus au sujet de deux choses ici -

1. Dois-je avoir juste une procédure stockée faire sql peut-être dynamique au lieu d'avoir comme une requête LINQ .Quand une procédure stockée doit-elle faire quelque chose au lieu d'avoir une requête LINQ? Je suppose que cela dépend ... mais quelles sont les meilleures pratiques? Quand devrait avoir une procédure stockée? Je vois parfois que LINQ fait des choses étranges et inefficaces dans les coulisses? Cela me préoccupe ..

2. Il y a lieu où je plusieurs ... choisit par rapport quand je peux joindre aux tables mais si entrer dans les rejoindre, il devient un peu plus complexe (disons 7-9 joint comme comparé à 3-5 Sélectionne). Je pense personnellement rejoindre serait efficace non? depuis une seule requête à la base de données? Alors qu'avec plusieurs sélections il doit faire plusieurs demandes? Quelles sont vos réflexions à ce sujet ?

Answer 1

Il y a beaucoup de facteurs qui contribuent ici et il y a beaucoup d'inconnues pour moi, donc le sous-texte pour ma réponse est "ça dépend".

1) Avec un Datacontext bien défini, LINQ-to-SQL génère généralement des requêtes efficaces. Les filtres sont automatiquement paramétrés, ce qui permet au moteur de la base de données de mettre en cache les plans d'exécution. Donc, je crois que la seule fois où les procédures stockées fonctionneraient mieux, c'est si des conseils de requête étaient nécessaires ou si un autre mécanisme n'était pas supporté par le générateur de requêtes. Je crois que la meilleure pratique est d'utiliser LINQ et d'utiliser seulement des sprocs lorsqu'une optimisation significative peut être démontrée. 2) En règle générale, limiter vos déplacements à la base de données est optimal. Mais en lisant le nombre de jointures requis dans votre relation, vous vous demandez si vous seriez bien servi en ajoutant une vue. Cela permettra d'abstraire la complexité, les vues s'intègrent bien avec LINQ et cela protégerait votre code contre les futures modifications de schéma. Je recommande également LINQPad pour aider à optimiser les requêtes LINQ-to-SQL. Il est devenu un outil indispensable pour moi et, si vous ne l'utilisez pas déjà, je parie qu'il deviendra aussi un pour vous. Pour plus d'opinions concernant LINQ vs SProcs consultez la discussion dans cette question: LINQ-to-SQL vs stored procedures?