Симонов ДенисSQL запросы написанные руками в некоторых случаях будут значительно быстрее, чем сгенерированные с помощью LINQ.В каких случаях?

Симонов ДенисАлексей К,

это не сложно выяснить самостоятельно. Включаешь трассировку и начинаешь писать запросы на LINQ постепенно усложняя их. Начнём с того что драйвер ADO.NET для Firebird начинает на каждый чих оборачивать предыдущий шаг в Devired table.Не замечал, чтобы вложенные запросы создавали проблемы для оптимизатора MSSQL. Это действительно так критично для Firebird, InterBase?
Симонов ДенисКогда дело доходит до того чтобы посчитать какие-то агрегаты с группировкой и джойном нескольких таблиц запрос начинает не просто ужасно выглядеть, но ещё и медленно выполняться. Этот запрос переписанный ручками, если конечно приложить мозги, выполняется в 10 раз быстрее.

ИХМО для аналитики LINQ не очень подходитЭто достаточно субъективная оценка.

Например ассоциации наоборот способствуют упрощению написания запросов с большим количеством задействованных таблиц.

Симонов Денисодно предложение вписать забыл

Начнём с того что драйвер ADO.NET для Firebird начинает на каждый чих оборачивать предыдущий шаг в Devired table. Благо это оптимизатор Firebird нормально разруливает. ...Ну и почему тогда этот факт вызывает сложности?

Симонов ДенисАлексей К,

я же сказал что сами по себе джойны с DT сложности у оптимизатора не вызывают, а вот если к этому добавить агрегаты с группировками, то будет уже туговато. Это проявляется из-за особенности делать группы по всем столбцам группируемого отношения. Я не могу привести пример прямо сейчас, но если интересно, могу повторить его дома в свободное время и выложить результаты.Но ведь LINQ не самовольно применяет вложенные запросы. Это происходит, например, при использовании оператора let . Никто не завтавляет строить запрос таким образом, если вдруг вложенные запросы начинают мешать.
Симонов ДенисДа и ещё это касается Firebird, у MS SQL совсем другой оптимизатор, да и я не пытался смотреть какие запросы в этих случаях генерируются для него.Не думаю, что там есть принципиальные отличия.
Симонов ДенисАлексей КНапример ассоциации наоборот способствуют упрощению написания запросов с большим количеством задействованных таблиц.

это оно так на LINQ просто выглядит, а ты посмотри во что это преобразуется на SQL.Преобразуется в обычные join , во что же ещё можно это преобразовать.
Симонов ДенисПоверь тем кто понимает SQL написать аналогичный запрос не составит труда и работать он будет эффективнее, другое дело как это потом самостоятельно отмапить на структуры EF, если оно вообще нужно для аналитики.Тут дело в удобстве написания, вероятности ошибок и уровне контроля на этапе компиляции.

Например, при использовании ассоциаций вероятность ошибочного объединения таблиц по неправильным полям равна 0. Разумеется, при выборе правильной ассоциации.

МимопроходящийHello, Алексей К!
You wrote on 20 сентября 2016 г. 10:47:22:

Алексей К> Не думаю, что там есть принципиальные отличия.не думай.

проходи.

Симонов ДенисАлексей К,

я не пойму ты чего тут защищаешь LINQ?Почему нет? Это запрещено правилами форума?
Симонов ДенисНу технология интересная, хорошо работает с коллекциями в памяти, даже хитрым образом преобразуется в прямой SQL запрос.Да.
Симонов ДенисНо пробовал ли ты работать конкретно с Firebird?Нет. Поэтому мне интересно твоё мнение по данному вопросу.
Симонов ДенисСмотрел ли ты в какие именно запросы преобразуются твои LINQ выражения?На MSSQL смотрел.
Симонов ДенисЯ пробовал. Если производительность достаточная, то мне собственно всё равно насколько страшно выглядит полученный SQL запрос, но вот когда её оказывается не достаточно, то смотря на тот ужас который был сгенерирован начинаешь понимать почему.Я всё понял, можешь не продолжать. Удачи!

Симонов ДенисТебе всегда хватает возможностей LINQ или всё же приходится что-то делать прямыми запросами?Да, LINQ не умеет генерировать, например, рекурсивные запросы. В этом случае рекурсивная часть запроса выносится во view, после чего LINQ работает с view как с обычной таблицей.

Симонов ДенисКстати вьюха в этом случае не очень то поможет, ибо не принимает параметров.Как скажешь.

Симонов ДенисАлексей К,

таки признаёшь что LINQ и EF без вставок чистого SQL не может обеспечить всех потребностей? Если у тебя есть решение, то очень хотел бы его увидеть. Просто интересно может я чего пропустил.С этим никто не спорит. Удивили какие-то "случаи" , в которых "SQL запросы написанные руками в некоторых случаях будут значительно быстрее, чем сгенерированные с помощью LINQ".