Есть LINQ2DB, он вот как раз чуть более норм в этом плане.

а потом прыгать с горящей задницей, когда руководство сказало, что мы теперь не можем пользоваться базой данных X, переезжаем на Y

Это экстремальные случаи актуальные очень мало где.

При том решается это всё равно репозиториями, а не ORM как таковым

я просто помню как в одной из прошлых контор, товарищ проповедовал, что надо всё делать хранимыми процедурами которые возвращают JSONы из MSSQL а потом сказали, что на скуль денег нет, едем на постгрес.

У нас есть две таблички: водилы и их расписания. Связаны один ко многим, расписаний может не быть. Нам нужно выбрать "айди водилы и поля расписания либо для всех водил, либо для тех водил у кого нет ни одного расписания (в зависимости от настройки @inactiveOnly)

Есть вот такой запрос который эту задачу решает

SELECT p."Id", array_agg(s."Id")
FROM dbo."Persons" p
   LEFT JOIN dbo."Schedule" s on p."Id" = s."EntityId"
where p."NicName" ILIKE '%test%' AND (.. more conditions)
GROUP BY p."Id"
HAVING WHEN @inactiveOnly THEN COUNT(s."Id") = 0 ELSE 1 = 1 END
ORDER BY p."Id"
LIMIT 20 OFFSET 0


Покажи как это на LINQ будет выглядеть

Хранимками можно так и не злоупотреблять, к тому же жсон отвратительный формат для подобных вещей

ну так я про то и говорю, что баланс важен. и для ряда задач ЕФ более чем удобен

И если что я раньше, лет 6 назад, тоже был фанатом дотнетовских ORM'ок, но как только оказался на проекте с базой в десятки терабайт, как-то очень быстро в целом к ним охладел.

Потому что выигрыш в скорости разработки не особо велик, а проблем и инфраструктурной цены у них дофига и больше

К тому же учат людей не правильным вещам

явно более громоздко)

поинт в том что не у всех терабайтные базы

именно

что есть "правильные вещи"?

на что твой ответ "а что вы будете делать если ВДРУГ у вас повалят клиенты и нужно будет расти? У нас вот такая ситуация была!"

на что ответ "многие компании по 5-10 лет таких объемов не достигают, посмотри на тот же атлас"

Поинт в том, что разница между 1 минутой на запрос на LINQ и 5 минутами на запрос на SQL - оно роли не играют

да не более громоздко, оно тупо не работает никак:

System.InvalidOperationException: The LINQ expression 'DbSet<Person>()
   .LeftJoin(
       inner: DbSet<Schedule<Person>>()
           .Where(s => s.DeletedOn == null),
       outerKeySelector: p => p.Id,
       innerKeySelector: s => s.EntityId,
       resultSelector: (p, s) => new TransparentIdentifier<Person, Schedule<Person>>(
           Outer = p,
           Inner = s
       ))
   .GroupBy(
       keySelector: ti => ti.Outer,
       elementSelector: ti => ti.Inner)' could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to 'AsEnumerable', 'AsAsyncEnumerable', 'ToList', or 'ToListAsync'. See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.

можно переписать на триллион подзапросов тока перфоманс такого решения будет сомнителен

EF подобные ORMы заточены прежде всего на операции с отдельными сущностями. Любые массовые запросы в них - это так или иначе проблемы и хитрости. Я уж молчу от эффект от lazy loading'а.

Change tracking и UoW особо не спасают, при этом жрут ресурсы как не в себя.

А главное правило при работе с большими реляционками - это всегда массовые запросы, если есть возможность, никаких отдельных запросов по сущностям, если без них можно обойтись.