Re[72]: Тормознутость и кривость linq
От: alex_public  
Дата: 01.05.16 04:13
Оценка:
Здравствуйте, IT, Вы писали:

_>>Так а пример то можно? ) Чтобы разница была не в соответствие синтаксису конкретной СУБД, а именно в оптимзиации.

IT>Я не совсем понимаю разницу, да и самой постановки задачи тоже. Есть разные СУБД, для них делается попытка построить наиболее оптимальный SQL, в том числе для разных версий СУБД. Возьмём, напрмер, пейджинг. Есть такой тест:

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

IT>>>Главная проблема не в оптимизации как таковой, а в наличиствующих инструментах. Дайте паттерн матчинг в C# и отжать всё лишнее из генерируемого SQL вообще будет не проблема.

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

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