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

IT>Опять же. Я не вижу здесь вообще повода для дискуссии. Сделать оптимизации для конкретного сервера и разный код для разных СУБД — это задачи одного порядка. Там где нужно всё это делается.

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

_>>Что-то сомнительно, сам же писал выше какие там проблемы возникают. ) Вот в предкомпилированные запросы я ещё верю, правда они не везде применимы и не так удобны.
IT>Это не вопрос веры. Не надо верить / не верить. Можно всять и протестировать. Или хотя бы посмотреть результаты существующих тестов.

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

IT>Тем более, что в плохом провайдере подготовка запроса это не всегда основные тормоза. Как правило тесты делаются на нешироких таблицах, в 3-4 целочисленных поля. Если же зарядить запрос на таблицу с 50-ю полями и вытащить из неё записей тыщ двадцать, то вполне может оказаться, что материализация этих данных в объекты и есть главные тормоза.

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

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

IT>Опять же. Я не вижу здесь вообще повода для дискуссии. Сделать оптимизации для конкретного сервера и разный код для разных СУБД — это задачи одного порядка. Там где нужно всё это делается.

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

_>>Что-то сомнительно, сам же писал выше какие там проблемы возникают. ) Вот в предкомпилированные запросы я ещё верю, правда они не везде применимы и не так удобны.
IT>Это не вопрос веры. Не надо верить / не верить. Можно всять и протестировать. Или хотя бы посмотреть результаты существующих тестов.

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

IT>Тем более, что в плохом провайдере подготовка запроса это не всегда основные тормоза. Как правило тесты делаются на нешироких таблицах, в 3-4 целочисленных поля. Если же зарядить запрос на таблицу с 50-ю полями и вытащить из неё записей тыщ двадцать, то вполне может оказаться, что материализация этих данных в объекты и есть главные тормоза.

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

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