Mit der folgenden Tabellenstruktur (überflüssige Spalten entfernt)
%Vor%Ich benutze die folgenden Linq-to-Entities-Abfragen:
%Vor%Produziert (von einem SQL Profiler):
%Vor% Warum generiert es in der dritten Abfrage ein LEFT OUTER JOIN in der Tabelle Events ein zweites Mal? Während die Abfrage korrekte Ergebnisse liefert, scheint es seltsam, warum EF / LINQ [Extent2] in der SELECT und WHERE -Klausel nicht wiederverwenden kann und warum ist es ein LEFT OUTER JOIN ?
Ich verwende Visual Studio 2010 sp1 .NET 4 und verbinde mich mit Sql Server 2008 Express.
Der linke Join würde sicherstellen, dass keine Zeilen in der Tabelle "Spenden" fehlen, falls eine Spende auf ein nicht vorhandenes Ereignis zeigt. Sie möchten nicht, dass das Include-Schlüsselwort den Nebeneffekt hat, dass Zeilen in der ursprünglichen Tabelle fehlen, sodass sie aus Sicherheitsgründen eine linke Verknüpfung verwenden müssen.
In Bezug auf die Aufnahme der Tabelle zweimal ist dies wahrscheinlich nur eine Einschränkung von EF. Sie erwähnen es zweimal in Ihrer Abfrage und es ist nicht schlau genug, um die Optimierung zu tun.
Ich muss sagen, dass, wenn Sie SQL optimieren und dann SQL schreiben möchten, sich nicht mit EF befassen. Was Sie tun, könnte mit dem Dekompilieren von C # verglichen werden und fragen, warum der Assembler keine bestimmte Optimierung hat. Wenn Sie EF verwenden, dann schließen Sie Ihre Augen, was SQL produziert: -)
Nicht direkte Antwort auf Ihre Frage, sondern ein Versuch, Sie in die richtige Richtung zu lenken, nachdem Sie Ihre Kommentare für die anderen Antworten gelesen haben:
Sie haben alles, was Sie brauchen, um eine ORM-Nachricht zu verteidigen (inkl. EF) - das ist alles, was Sie über die Quantität und Qualität der SPs gesagt haben. Jeder Ansatz wird Probleme haben, einschließlich pure sql, wenn dieser sql nicht gut geschrieben oder schwer zu pflegen ist.
Wenn also ein ORM (EF usw.) manchmal nicht effizienten Code erzeugt und dies wirklich Leistungsprobleme verursacht, wird dies zu einer "Anforderung" und muss gelöst werden, selbst mit SP.
Sehen Sie sich also Ihre Probleme aus der Geschäftssicht an - Sie haben einen schlecht strukturierten und schwer zu wartenden Haufen gespeicherter Prozeduren. Wahrscheinlich ist der größte Teil Ihres Teams C # und nicht SQL-Entwickler.
Die Verwendung von ORM erhöht die Wartbarkeit der Codebasis und ermöglicht eine bessere Nutzung aller Teammitglieder in C #.
Schlechter SQL-Code, der von ORM zu bestimmten Anlässen erzeugt wird, ist für die Verwendung der Technologie kaum "no-go", es sei denn, es wird bewiesen, dass es mehr Probleme schafft als das Lösen bestehender.
Tags und Links c# entity-framework linq linq-to-entities