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

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

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



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

S>>Не верю.
G>Можешь проверить


S>>Во-первых, надо смотреть на план linq запросов, которых аж целых 8 вместо 1.
G>Тогда идея с рукопашными запросами покажется совсем глупой. Потому что у каждого запроса из 8 будет свой оптимальный план.
G>А рукопашный запрос вида
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>Будет иметь план, который оптимален только для одного из 8 сочетаний параметров. Чем больше параметров тем хуже, никакие индексы не помогут. Поможет только option (recompile), но добавит затраты на компиляцию запроса каждый раз.

G>Погугли советы использовать option (recompile), почти везде вместо него можно использовать генератор запросов.

А linq то как поможет?

S>>Во-вторых, спорно ибо нормальный спец. в рбд. напишет может написать запрос явно не хуже чем чем linq сгенеренный.
G>Нормальный спец напишет запрос явно не хуже, чем linq. ОДИН запрос.
G>Поддерживать самописный генератор или несколько десятков однотипных запросов даже "нормальный спец" не сможет.

Вы смеетесь ??? Т.е. если Вы возьмете человека на фул-тайм с задачей написания 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
G>>>lazy load надо отключать всегда и лучше не пользоваться ORM где он включен. В EF он отключен по-умолчанию для code-first, а в linq2db его вовсе нет.
S>>да-да-да, и сразу подгружать всю базу данных со всеми join'ами, которые не нужны.
G>Ты о чем сейчас?

Ну как-бы у openaccess telerik'овского допустим есть eager loading и laze loading (как и везде). При подгрузке родительских сущностей все дочерние сущности соотв родительской тоже подгрузятся, даже если они не нужны.