Re[73]: Тормознутость и кривость linq
От: IT Россия linq2db.com
Дата: 01.05.16 18:15
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Ну так вот прямо этот пример мы тут разбирали уже. И это как раз классический пример следования особенностям синтаксиса конкретной СУБД (просто через соответствующий вызов функции провайдера). Это как бы везде такое тривиально реализуется.


Это смотря как на это посмотреть. Пейджинг без специфических вещей конкретной БД делается простым проматыванием ненужных данных до нужной страницы. Но это не эффективно. Поэтому для каждой БД такой запрос преобразуется в более подходящий вариант. Если заметил, то и для разных версий БД это тоже делается.

В общем, это чисто терминологический спор. Где у нас оптимизации, а где код, заточенный под конкретную СУБД.

_>Мне тут обещали совсем другое, реальную умную оптимизацию. Что типа ORM будет в зависимости от вида СУБД менять join'ы на подзапросы или что-то такое, т.к. они в ней быстрее выполняются. В общем какие-то реальные оптимизации, а не следования синтаксису (собственно ты ему физически не можешь не следовать, так что это не оптимизация, а просто минимальная реализация).


Делается. Только наоборот. Подзапросы меняются на джоины. Точнее на OUTER APPLY. SQL Server поддерживает такую фичу и для него такая замена делается.

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

IT>>Да. Есть такое волшебное слово — кеширование, которое позволяет забить на проблемы производительности.

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

Это не вопрос веры. Не надо верить / не верить. Можно всять и протестировать. Или хотя бы посмотреть результаты существующих тестов.

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