Когда стоит использовать ORM, а когда сырые SQL запросы

Что проверяют

Умеете ли вы выбирать инструмент по задаче и понимаете ли, чем ORM платит за удобство.

Как отвечать

ORM выигрывает там, где операции простые и однотипные: CRUD по сущности, чтение по первичному ключу, миграции, единая модель данных в коде, защита от инъекций по построению. Он экономит много рутины и держит схему и код в согласии.

Сырой SQL нужен там, где важна форма запроса: аналитические выборки с оконными функциями, сложные соединения, специфика конкретной СУБД (ON CONFLICT, LATERAL, полнотекстовый поиск, jsonb), пакетные операции над миллионами строк, тонкая оптимизация по плану.

Практика обычно смешанная: ORM на девяносто процентов кода, отдельные тяжёлые запросы руками. Все взрослые ORM это позволяют: в SQLAlchemy есть text() и Core, в Django raw() и annotate, в Hibernate нативные запросы.

Что стоит назвать как цену ORM: проблема N+1, когда обращение к связи в цикле превращается в тысячу запросов; неочевидная генерация SQL, из-за которой план оказывается плохим; ленивая загрузка вне сессии; накладные расходы на отображение объектов при больших выборках.

Ключевая мысль: ORM не освобождает от знания SQL. Он избавляет от рутины, но отлаживать всё равно придётся сгенерированный запрос и его план.

Где спотыкаются

Считают ORM заменой SQL и не умеют читать сгенерированный запрос.

Не знают про N+1 или знают термин, но не могут назвать лечение (join fetch, selectinload, prefetch_related).

Уходят в сырой SQL везде и теряют миграции и типобезопасность.

Собирают сырой запрос конкатенацией строк, открывая инъекцию.