Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Gattaka, Вы писали:

G>>>Здравствуйте, IT, Вы писали:

IT>>>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
G>>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.

G>>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

S>По-моему наоборт -- на sql можно четко сформулировать запрос без всяческих подпрыжек
Нельзя, если запрос параметризованный.

типичный случай для приложения — отображение списка с фильтрами — 3 фильтра+постраничная разбивка. Фильтры по умолчанию не фильтруют ничего и могут быть выбраны в любой комбинации. Linq сгенерирует 8 или 16 разных запросов для различных сочетаний фильтров и страниц.
На SQL будет написан один запрос с тремя условиями примерно такого вида:

where 1=1
and (t.Field1 = @p1 or @p1 is null)
and (t.Field2 = @p2 or @p2 is null)
and (t.Field3 = @p3 or @p3 is null)

План запроса в этом случае будет далек от оптимального и подвержен parameter sniffing problem.

Тут подробно http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/

В реальности еще добавится сортировка и разные проекции в запросах с одинаковыми предикатами. Общее количество возможных запросов перевалит за 50. При этом такой запрос будет на главной странице и должен работать максимально быстро. Linq тут очень поможет, а в SQL это будет АД.

S>вот с linq недавно огрбеб -- http://docs.telerik.com/data-access/developers-guide/profiling-and-tuning/profiler-and-tuning-advisor/data-access-profiler-n-plus-one-problem
lazy load надо отключать всегда и лучше не пользоваться ORM где он включен. В EF он отключен по-умолчанию для code-first, а в linq2db его вовсе нет.