Подскажите, как вы терпите эти слооожные вложенные запросы с десятками полей с маловразумительными названиями полей и декартовыми произведениями, которые на выходе из 10 тысяч строк получают 10 строк ?

Много людей носят EF на руках и пропагандируют. И кто-то попадается в их сети. Попадаются на фразы, встреченные в айтишных журналах "попробуй, первый раз бесплатно и будет приятно писать код". А потом прикручивают это к серьезному проекту и затем уже страдают не в силах вырваться из этой пагубной привычки (я все еще про EF пишу), т.к. это потребует переписывания большого куска программы.

Как вы оптимизируете получающиеся запросы? Когда пользователь жалуется на медленный запрос, вы ловите его с поличпрофайлером и затем вдууумчиво разлядываете запросы со вложенностью 10, пытаясь понять что же тут тормозит.

Как ?

Shocker.Pro,

Запросы со сложной вложенностью можно легко получить где угодно. Например, найти всех User'ов у которых выполняется условие - найти все их документы, к которыми связанны договоры и даты этих договоров находятся в периоде от и до. Такой просто запрос запросто сгенерит проблемный запрос и выдаст тысяч 10 строк, из которых EF соберет всего 10.
И что, вы предлагаете отказаться от использования EF везде где могут встретится такие ситуации ? Полагаю это 100% приложений.
А значит EF не пригоден везде, кроме как студенческом проекте.

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

Shocker.Pro,

Ну погодите. типичная же ситуация ). "Найди ка мне всех раздолбаев, которые назаключали договоры 31-го дкабря и 1-го января. Они очевидно были выпимши, я хочу их наказать". Такая простая задача уже сделает запрос с 3мя вложенностями куда EF вставит десятки полей с именами А1, A2 и т.д.

И вложенность может быть в итоге и еще больше - можно еще подтянуть всех customer'ов, привязанных в договоре А ТАКЖЕ их контакты, чтобы принести им извинения по телефону. И вот, имеем вложенность 5 ! И десятки малочитабельных полей и декартовы произведения из десятков тысяч сущностей.

И вот потом как это все отлаживать или профилировать, не ясно вообще. Такие сложные запросы это проза жизни разработчика EF. Большинство запросов, выходящих за простенький CRUD вылезают в это. Это не какая-то редкость. Это норма.

fkthat,

ну видимо он не знал про отложенное выполнение и путал iQueriable и iEnumerable )
Я то не про это говорю вообще )

Shocker.Pro,

Итоговый, стандартный запрос.
"Найди ка мне всех раздолбаев, которые назаключали договоры 31-го дкабря и 1-го января. Также всех customer'ов, привязанных к этим договорам и их контакты НЕ помеченные как НЕ ЗВОНИТЬ и которым мы еще никогда не звонили (что хранится в виде истории, в другой таблице)" Как вам такой просто запрос на человеческом языке, которые сгенерит кашу в EF ? :)

fkthat,

проблема в том, что там я сам не понимаю что он сгенерил.
Особенно EF любит делать все через Union.

Он может запросто взять этот сложный запрос, описанный мной и обединить его так:

............................. очень много фигниииии.................
................................. ну ооооооочень много...................
.............. поля, поля, круком поля F1, F2, A1, какие только хочешь
..................... where x != 1
...... а тут еще больше полей, чтобы было интересней
...... аааа и тут тоже.
.... и здеся

union


............................. очень много фигниииии.................
................................. ну ооооооочень много...................
.............. поля, поля, круком поля F1, F2, A1, какие только хочешь
..................... where x != 2 OR where x > 3
...... а тут еще больше полей, чтобы было интересней
...... аааа и тут тоже.
.... и здеся


И вот ты такой смотришь на этот чертов запрос и охреневаешь ! 500 строк склеивается с еще 500тами и разница между ними в 5 символах. В 5ти символах Карл ! А рядом стоит юзер и ругается, что у него отчет не генерится, потому, что соединение отваливается по таймауту и мне нужно найти где проблема и что тормозит. Но для начала все таки понять что делает запрос.

Вот как разработчики EF с этим живут, справляются и не спиваются ?

fkthat,

Ну что вы такое говорите. Для простых запросов из трех (пяти) связанных таблиц, из которых EF делает кашу, городить OLTP.
Этак получится, что нужно делать OLTP Для всего, где может встретится хоть один Join.

fkthat,

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



Как я понимаю, вы считаете, что для такого рода запросов EF не предназначен да ? Тогда для чего предназначен EF, кроме школьных лабораторных, где могут встретится только задачи вида "дай мне все апельсины красного цвета и вес которых не больше 500 грамм".

WebPrj,

Не могу показать даже сейчас. В последних проектах отказались от EF. Надоело с ним возится, и старых проектов в эксплуатации, с EF уже нет. Но решил создать эту тему, чтобы понять как другие существуют с этим EF, может как-то справляются с этим всем.
Может найду ответы и снова вернусь к EF. Хотя и не очень хочется, но приходится поддерживать какие-то тренды...

Все эти сложные запросы у меня бывали, с юнионами в том числе. Спровоцировать их вполне реально, неужели у пользователей EF такого никогда не было и это я (мы) настолько не умею его готовить ? Не поверю.

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

Все таки хочу уточнить.
Никто не сталкивается с тем, что EF генерит SQL запросы вида



Как я написал выше, спровоцировать такой запрос очень просто. Достаточно, чтобы по условии задачи у вас были какие-то логические условия, применяемые к навигационной проперти 4-5го уровня вложенности. Такого не избежать. Точнее можно, но для этого придется тянуть на клиента Ienumerable верхнего уровня и потом через foreach спускаться вниз, но это, очевидно не правильно.

Также я не помню точно, но много раз видел, что EF разбивает условие на два большие фактически идентичные и объединяет их через Union. Ни у кого из вас такого не было ?

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

Т.е. мы тут имеем выбор:
- пользуйся EF, но делай простые запросы и сложный алгоритм в коде. Фактически вместо eager loading работай с lazy loading реализованным вручную !
- либо не используй EF, и тогда сможешь использовать сколь-угодно сложные и эффективные, читабельные запросы.

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

Shocker.Pro,

С этим пожалуй могу согласится. Читал в MSDN magazine про какой-то Query Types, который добавили в EF 2.1.
https://msdn.microsoft.com/magazine/mt847184

Сильно не вникал, ибо не практикую EF, но как понял добавлена возможность работать "не с сущностями" получая их из чистого SQL:



Однако это дна из недавно добавленных фич. Возникает вопрос, как до этого жить и жили программисты ?

Вот вы мне опять предлагаете какие-то обходные пути, чтобы избежать сложного запроса. А я выше как раз и задал вопрос - это что базовое правило ? EF только если нужно получить "документ по ID ну и, может быть, его создателя. Максимум !" ? А если нужно поработать с зависимыми сущностями, то пожалуйста делай 5 вложенных foreach'ей и пиши кучу логику.


Я сталкивался с такими сложными запросами, просто потому, что логика того требовала. Как его избегаете Вы ? А если не избегаете, значит видели эти сложные вложенные запросы с кучей unio'ов, то как вы с этим работали, отлаживали ? Об этом и топик.

Petro123,

Выше я написал, что у меня нет примеров. Не практикую EF давно, избегаю в проектах.
Но у меня и вопрос к пользователям EF - они что, не видели такого ? Я один это видел ? А весь остальной мир живет в счастливом мире читабельных EF запросов. Я надеялся, что у тех кто практикует EF эти примеры есть прямо сейчас в самых разных вариантах.
И у меня вопрос, как же другие избегают этих запросов ? Как я и написал - через вложенные foreach'и где логика реализуется уже на C# ?