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

I>Это давно известные вещи — как только появился запрос, следующая таска — сделать его быстрее. Вот девелопер добавил присваивание и обвалил перформанс. Как ему объяснить, какого вида код работает хорошо, а какой- плохо ?

Никак. Разработчик замерит сам.
Я же ссылку дал, где чёрным по белому написано, что перформанс обваливают как раз сложные запросы.
А батч из последовательности простых не обваливает.
Т.е. сам батч вроде бы выполняется дольше, чем сложный запрос, но зато сложный запрос лочит пол-базы, а пошаговый батч — лишь отдельные строки таблиц в каждый момент времени, что повышает уровень параллелизма многократно.


I>В Linq у нас это заложено в архитектуру — дели запрос на операции, Select, Where и тд. В твоем случае изначально никакого разделения не предусмотрено

Херня эта архитектура.
РСУБД — тормоза и ненадёжность.
https://habr.com/company/odnoklassniki/blog/417593/

Прелесть РСУБД в том, что они дают достаточную надёжность и богатый функционал подпорок/ограничений прямо изкаробки, что покрывает львиную долю простых сценариев.
Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.


V>>Т.е. ты продолжаешь отрицать полезность батчей? ))
I>Попробуй переписать обычный SQL в импративное управление курсором. Померяй перформанс.

Батч не равен курсору.
Батч спокойно оперирует множествами.