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

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), но добавит затраты на компиляцию запроса каждый раз.

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

C linq будет написан такой код:

if(p1 != null) q = q.Where(t => t.Field1 = p1);
if(p2 != null) q = q.Where(t => t.Field2 = p2);
if(p3 != null) q = q.Where(t => t.Field3 = p3);

В итоге в зависимости от параметров будет 8 запросов, каждый с оптимальным планом под свое сочетание параметров. Каждый из 8 запросов может быть оптимизирован своим индексом.


S>Вы смеетесь ??? Т.е. если Вы возьмете человека на фул-тайм с задачей написания sql запросов (специалиста), он больше одного запроса написать не сможет? Не считая того, что вообще говоря это должно быть компетенцией разработчика, отв. за соотв. таблицы (сущности).
Конечно сможет. И два сможет, и десять и может даже 50. Для статистики — у меня в очень простом приложении с 5 таблицами в базе получилось суммарно 60 разных запросов. А нанимать спеца отдельно по БД для базы менее чем два десятка таблиц никто не будет. Вот и посчитай какое количество запросов ему надо будет поддерживать.


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