Entity-Framework generiert ineffizientes SQL

Question

Ich frage mich, warum Entity Framework eine solche ineffiziente SQL-Abfrage generiert. In meinem Code erwartete ich die WHERE auf das wirken, umfassen:

db.Employment.Where(x => x.Active).Include(x => x.Employee).Where(x => x.Employee.UserID == UserID) 

aber ich mit einem Doppel-SQL JOIN endete:

SELECT [x].[ID], [x].[Active], [x].[CurrencyID], [x].[DepartmentID], [x].[EmplEnd], [x].[EmplStart], [x].[EmployeeID], [x].[HolidayGroupID], [x].[HourlyCost], [x].[JobTitle], [x].[ManagerID], [x].[WorkScheduleGroupID], [e].[ID], [e].[Active], [e].[Address], [e].[BirthDate], [e].[CitizenshipID], [e].[City], [e].[CountryID], [e].[Email], [e].[FirstName], [e].[Gender], [e].[LastName], [e].[Note], [e].[Phone], [e].[PostalCode], [e].[TaxNumber], [e].[UserID] 
FROM [Employment] AS [x] 
INNER JOIN [Employee] AS [x.Employee] ON [x].[EmployeeID] = [x.Employee].[ID] 
INNER JOIN [Employee] AS [e] ON [x].[EmployeeID] = [e].[ID] 
WHERE ([x].[Active] = 1) AND ([x.Employee].[UserID] = @__UserID_0) 

Ich fand heraus, dass diese Abfrage besser SQL schaffen:

db.Employment.Where(x => x.Active).Where(x => x.Employee.UserID == UserID) 

SELECT [x].[ID], [x].[Active], [x].[CurrencyID], [x].[DepartmentID], [x].[EmplEnd], [x].[EmplStart], [x].[EmployeeID], [x].[HolidayGroupID], [x].[HourlyCost], [x].[JobTitle], [x].[ManagerID], [x].[WorkScheduleGroupID] 
FROM [Employment] AS [x] 
INNER JOIN [Employee] AS [x.Employee] ON [x].[EmployeeID] = [x.Employee].[ID] 
WHERE ([x].[Active] = 1) AND ([x.Employee].[UserID] = @__UserID_0) 

jedoch das Problem hier, die Entitäten referenziert werden nicht von der DB abgerufen.

Warum erzeugen zwei Codes nicht dieselben SQL?

Answer 1

Die SQL unterscheidet sich, da die Anweisungen unterschiedlich sind.

Entity Framework ineffizient TSQL produziert, hat es immer. Durch Abstrahieren der Feinheiten, die für SQL mit guter Leistung notwendig sind, und ersetzen sie durch "Gürtel und Klammern" fast immer arbeiten Alternativen Sie Sacrafice Leistung für Dienstprogramm.

Wenn Sie eine gute Leistung benötigen, schreiben die SQL selbst. Dapper funktioniert gut für mich. Sie können nicht realistisch eine "one size fits all" Lösung erwarten, um den besten Code für Ihre spezifische Situation zu finden. Sie können dies auf der ganzen Linie oder nur dort tun, wo Sie es brauchen.

Sofern Sie hochvolumigen oder spezifische Leistungsanforderungen haben wieder mit ihm und verwenden, was Sie am einfachsten zu finden. Wenn Sie Ihre Abfragen auf Ihre Datenbank abstimmen müssen, werden Sie die Details Ihrer Datenbank-Engine erfahren und die Abfragen selbst implementieren. Wenn Sie erwarten, dass die nächste Iteration von Entity Framework das Wundermittel ist, das Ihnen schnellen, effizienten SQL-Datenzugriff mit minimalem Wissen ermöglicht, viel Glück.

P.S.

Off-topic, aber NoSQL wahrscheinlich nicht die Antwort entweder, ist nur eine andere Klasse von Datenbank.