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

_>Хы, ну просто если считать и такие синтаксические вещи, предоставляемые провайдером, за оптимизацию, то тогда можно сказать, что и во всех библиотечках абстрагирующих запрос в СУБД от вида конкретной СУБД есть умные оптимизации. )))

Ты бы тогда дал определение оптимизации под конкретную СУБД. OUTER APPLY это тоже не оно? Ты почему-то решил опустить эту часть, что не совсем понятно.

_>Ну вот тесты как раз показывают, что появляются вполне себе ощутимые накладные расходы.

Какие именно тесты?

_>Безусловно. И тесты опять же подтверждают твои слова. Только вот как раз чаще бывают запросы на небольшое число строк в результате (т.к. пользователю редко нужно лицезреть сразу тысячи строк).

Чаще бывают у кого?

_>Более того, одним из самых популярных в веб'е запросов всегда был запрос на данные пользователя по идентифицирующей его сессии, который исполняется практически мгновенно (запрос на индекс с единственной строкой в результате).

Есть такое дело. На этом сайте в том числе. И как-то оно работает себе и работает.

Это всё не проблема. Вообще ни разу. Моя последняя возня с оптимизацией запросов вообще не имеет никакого отношения к linq. В основном это изучение плана запросов, создание индексов, партиционирование и т.п. С linq возникают только проблемы поддержки конкретной базы. Например, на C# нельзя выразить рекурсивный CTE. Пичалька TABLE и QUERY hints сделали, а до JOIN hint всё руки никак не дойдут.

Вот где проблемы. А производительность вполне устраивает и даже более чем. К тому же, например, в том числе и на этом сайте переписывание некоторых запросов с сохранённых процедур и прямого SQL позволило существенно увеличить производительность. Правда странно? А всё дело в выразительности используемых средств. Там где SQL девелопер родит один запрос, я на linq напишу его 5 раз и попробую разные варианты. Там где SQL девелопер напишет что-то типа WHERE @p IS NULL OR Field1 = @p, чтобы не заниматься склейкой строк, я поставлю if в коде и получу гораздо более оптимальный SQL. И т.п.

К тому же linq2db вообще не ограничивает девелопера никаким образом. Считаешь, что данный конкретный запрос лучше написать ручками — хоть оппишись. Сам себе злобный буратина. Таких запросов как ты упомянул обычно 1-2 на всё приложение. Напиши их на SQL, если даже CompiledQuery не устраивает.

_>P.S. О, кстати, давно хотел спросить у кого-нибудь разбирающегося (а то лень смотреть по документациям). Предкомпилированные запросы в linq2db, EF и т.п. библиотеках включают в себя только предкомпиляцию sql строки или же включают в себе и предкомпиляцию запроса внутри СУБД?

А такое возможно в принципе?