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

HBM>>>оптимизировать sql нужно тогда, когда есть проблемы с перфомансом. 90% операций приложения это таки CRUD, а с ним любая ORM отлично справляется.
G>>Ерунда. Нужно сразу писать оптимальный код. Преждевременная пессимизация приводит к проектам, которые и за полгода не отрефакторишь.
HBM>преждевременная оптимизация не меньшее зло. код должен быть нормальным, но нет смысла гнаться за +1% перфоманса.

Это неверно.

Когда Дейкстра писал про преждевременную оптимизацию он имел ввиду мелкие хаки на уровне отдельных команд процессора, которые дают незначительный прирост быстродействия, но значительно ухудшают читаемость.
Частично это же касается выбора алгоримтма, типа лучше сначала запилить линейный поиск, чем ловить баги в двоичном поиске с интерполяцией.

Но когда мы говорим о высокоуровневой оптимизации — на уровне структур данных, взаимодействия компонентов, базы данных, то оптимизировать нужно с самого начала, иначе потом цена исправления растет экспоненциально.
Оптимизация SQL касается как раз такого вида оптимизации.

У меня есть прекрасный пример. В 2008 году, когда только появился linq, я делал сайт и один человек из моей команды занимался построением навигации.
Нужно было сделать нетривиальный запрос, который сделает выборку.

Это человек следуя подходу "потом оптимизируем" написал вместо сложного запроса пару foreach циклов. Мало того, что получил select n+1, так еще и код представления ориентировался на объекты модели, каждый из которых требовал поднятия по несколько КБ текста. В итоге навигация строилась полсекунды.

Я ему сказал, что надо переписать это дело в запрос и сделать проекцию, но он сказал, что это фигня и лучше мы применим кэш. И прикрутил кэш для объектов модели.
Потом мы на сайте прогрузили реальные данные клиента и получилось на построение навигации 8 секунд. Даже отлаживать стало неудобно, даже кеш не помогал, ибо разработчик запускал с нуля приложение чуть ли не каждую минуту.

В итоге надо было переделать запросы, сделать DTO, переделать код представления, переделать механизм кеширования. По сути переписать ВСЕ, что делал этот программист.
Вот такая цена неоптимальных запросов.

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