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



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

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

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

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

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

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


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

да-да-да, и сразу подгружать всю базу данных со всеми join'ами, которые не нужны.