Так вроде  и делается всегда)

Да но выше было радикальное утверждение что орм годиться только для прототипирования на коленке и не стоит его использовать

Ну у каждого свой опыт использования видимо

Так этот опыт мне и интересен

Но к сожалению ни аргументов ни примеров нет

Дальше рассуждать могут только те, кто смотрел в логи sql-запросов после своей ORM

То есть создаём 100500 квери объектов в ручную или есть другие альтернативы?

Смотрел SQLAlchemy в моём случае 95% запросов оптимальны оставшиеся 5% пишем руками

Да генерит часто избыточные запросы но не настолько что бы это сказывалось на производительности

СУБД позволяет  опускать очевидные парамтеры, а ORM их не опускает. Поэтому эта избыточность тоже довольно условна

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

И все же какие альтернативные практики?

ORM это техника/подход конкретные  реализации active record, ROM

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

То есть вы имеете ввиду работу с  результатом запроса как с структурой данных, типа map или struct?

в цепочке RAW SQL -> Запрос -> результат запроса я имею ввиду

Ну нет смысла перекладывать в экземпляры класса, да и класс не нужен

ты против ооп в целом или АНТИORM подход относится только при взаимодействии с реляционными бд?

Есть задачи, в которых ООП очень эффективно, например: UI, обертки вокруг абстракций операционной системы, такие, как сокеты, файловые потоки, таймеры и т.д, драйвера для БД и других внешних сервисов, как почтовые системы, смс шлюзы, шины событий, API внешних систем, особенно с установлением соединения и с состоянием, это очень хорошо ложится на ООП. Но вот для чего его плохо применять: вычисления, растровый рендеринг, обработка сигналов, различные алгоритмические задачи (подавляющее большинство, но не все) и ООП категорически не подходит для информационного моделирования предметной области. Для этого лучше всего использовать анемичные структуры данных (не содержащие поведения), а вся бизнес-логика должна быть вынесена в отдельный слой API. В ОРМ же 70% действий - это перекладывание из одних структур в другие.