Dima TОптимизатор БД не переоценивай. В MS SQL он продвинутый, но не сильно. На сложных запросах может выбирать очень неоптимальные планы выполнения.

Неоптимальный план выполнения будет только при изначально неправильно составленном запросе.
SQL гибок, так, что одно и то же, можно получить большим количеством запросов.
Есть много сахара, позволяющего сократить запрос, поэтому многим кажется, чем короче выглядит запрос (особенно с применением сахара), тем он быстрее.

Это не так.

hVosttбольшим количеством запросов.

*способов

Дмитрий МухА что значит неправильно? Получившийся в начале топика запрос он как составлен?

Ну и сильное конечно утверждение: "только при изначально неправильно составленном запросе"

Это нормальное утверждение. Посмотри на LINQ запрос в начале топика с точки зрения коллекции объектов. Посмотри на получившийся запрос в SQL. Сделано ровно то, что было запрошено в LINQ.

Если запрос LINQ собирается динамически, то гарантировано всё будет правильно работать.

Ты начинаешь смотреть на задачу иначе с точки зрения объединения запросов или оконных функций, будучи уверенным, что это действительно _на порядки_ будет быстрее. С чего вдруг-то?

Неправильно составленный запрос, это который также неоптимален, или неверен и в LINQ.

Дмитрий МухhVosttЕсть много сахара, позволяющего сократить запрос
Например?

with, расширяющие функции, раширенные функции и операторы для группировки, оконные функции, дофига всего.

Дмитрий МухИ почему же это сахар? К примеру в курсе как работают оконные функции под капотом?

В курсе, не во всех случаях конечно.

Скажи ещё, не знаешь, как, например, пронумеровать записи без оконных функций? ))

Дмитрий МухЯ знаю как переписать запрос в стартовом посте не в четыре этажа, а в один, гораздо короче и без оконных функций.

Да, но это будет другой запрос. Даже если он будет возвращать аналогичные результаты. Просто прочитай, что задекларировано в LINQ. А если вот эти Count-ы, будут использовать динамические LINQ выражения, или вообще всё строится на спецификациях? Не всё так просто, как может показаться в лоб.

Да и в LINQ можно переписать запрос, вот эта задача выглядит по-интереснее.

Или нам не нужны Count-ы в результатах, а как условие для сортировки или фильтрации, м?

skyANAhVosttИли нам не нужны Count-ы в результатах, а как условие для сортировки или фильтрации, м?
Перечитай первое сообщение в топике

Ну я немного шире гляжу на задачу. Понятно, что если чисто в конкретные данные упираться, то да, там типа запрос компактный можно написать, но как это сделать в рамках EF? Не было сказано.

Дмитрий МухТС не знал, как написать на SQL то, что ему надо, и написал на LINQ.
Посмотрел сгенерированный текст запроса и понял, что сам бы он скорее поседел, чем додумался до решения на SQL.
Вынес это "достижение" на форум и спалился.

Какие динамические выражения? Какие спецификации? Я тебя умоляю

Ну это не интерсно. На SQL может любой, а как насчёт в EF?

skyANAДля начала .Sum() вместо .Count() попробовать?

Ну да, а ещё в LINQ можно несколько запросов с одним джойнить, проблема только с outer join.