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

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

G>Это неверно.

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

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

<... пример реализации через жопу скипнут...>

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

то что ты описываешь не совсем верно. Из того что я видел, пример преждевременной оптимизации на высоком уровне обычно такой:

Дизайним что-то крупное. И в процессе раскопок потенциальных проблем видны несколько бутылочных горлышек. Какое именно будет главным зависит от поведения пользователей, а его никто не знает(вот так построены бизнес процессы в компании что никто точно не знает как будут использовать фичу/компоненту/продукт, и даже как используют текущие фичи. Т.е. нормальных предположений сделать нельзя.). Тут встает "архитектор" и выдает: "Модель нагрузки будет вот такой <описание фантазий>". Поэтому мы всю архитектуру, заточим под скорость на такой модели. Причем под этими фантазиями нет никаких фактов, просто человеку так показалось. В случае если он не угадает, такую "заоптимизированную" систему переделать под другую модель нагрузки намного сложнее чем нейтральную. И соответственно нормальное решение, в ситуации когда мы не знаем точно что будет горлышком, сделать нейтральную модель и знать как мы будем отслеживать горлышки, что будет делать сапорт в этот момент, как будем менять поведение системы, когда любая комбинация из них сработает...

Опять же зло предварительной оптимизации не должно оправдываться решением через жопу. Если сразу видно, что решение не держит расчетную нагрузку — в топку его.