Dlaczego LINQ-to-Entities umieścić to zapytanie w sub-select?

Question

Mam następujące kwerendy LINQ:

var queryGroups = (from p in db.cl_contact_event 
        select new Groups { inputFileName = p.input_file_name }).Distinct(); 

co przekłada się na następujące po uruchomieniu:

SELECT 
[Distinct1].[C1] AS [C1], 
[Distinct1].[input_file_name] AS [input_file_name] 
FROM (SELECT DISTINCT 
     [Extent1].[input_file_name] AS [input_file_name], 
     1 AS [C1] 
     FROM [mel].[cl_contact_event] AS [Extent1] 
) AS [Distinct1] 

Teraz jestem pewien, że powód jest sub-select jest bo mam podstawowe zapytanie LINQ otoczone przez(), a następnie wykonaj .Distinct(), ale nie wiem wystarczająco dużo o LINQ, aby być tego pewnym. Jeśli tak jest, to czy istnieje sposób na restrukturyzację/zakodowanie mojego zapytania, aby nie doszło do sub-wyboru?

Wiem, że prawdopodobnie wydaje mi się, że po prostu wybieram nit, ale jestem po prostu ciekawy.

Answer 1

W tym podejrzewam, że rzeczywistą podstawową przyczyną podzapytania jest anonimowy konstruktor typów. Ponieważ nie wybieramy znanej jednostki, ale raczej arbitralnego obiektu zbudowanego na podstawie innych wartości encji, parser EF musi upewnić się, że potrafi wygenerować dokładny zestaw pól - czy z pojedynczej tabeli, połączonych tabel, pól obliczeniowych, innych pod-zapytania itp. Parser drzewa wyrażeń jest bardzo dobry w pisaniu instrukcji SQL z zapytań LINQ, gdy tylko jest to możliwe, ale nie jest wszechwiedzący. Przetwarza zapytania w sposób systematyczny, który zawsze przynosi poprawne wyniki (w tym sensie, że dostajesz to, o co prosiłeś), ale nie zawsze optymalne wyniki.

Jeśli chodzi o przepisywanie zapytania w celu wyeliminowania sub-select, najpierw: Nie widzę oczywistego sposobu, aby to zrobić, aby wyeliminować anonimowy typ i uzyskać poprawne wyniki. Co ważniejsze jednak, I nie przeszkadzałoby. Nowoczesne serwery SQL, takie jak Sybase, są bardzo inteligentne - często mądrzejsze od programisty - i bardzo dobre w tworzeniu optymalnego planu zapytania z zapytania. Poza tym EF uwielbia zapytania podrzędne, ponieważ są one bardzo dobrym sposobem pisania złożonych zapytań w sposób zautomatyzowany. Często można je znaleźć nawet wtedy, gdy zapytanie LINQ nie pojawia się z nich. Próba wyeliminowania ich wszystkich ze swoich zapytań szybko stanie się ćwiczeniem daremności.

Answer 2

Nie martwiłbym się tą szczególną sytuacją. SQL Server (i najprawdopodobniej dowolna korporacyjna baza danych) i tak zoptymalizuje zewnętrzną instrukcję Select. Teoretyzowałbym, że powodem generowania tej instrukcji SQL jest to, że jest to najbardziej ogólne i wielokrotnego użytku instrukcja. Z mojego doświadczenia wynika to zawsze z Distinct().