еще до задачи

ну там такая разница "поверх прямых запросов в бд", что если начинать оптимизировать, то едва ли это будет узким горлышком т.к. вылезет много другого (хотя бы уже производительность di библиотеки/контейнера) т.е. оверхед есть ест-но (просто потому что есть прослойка), опр. кеш выражений на уровне транслятора тоже вполне есть. и это еще с учетом того, что нужно иметь такой кейс для оптимизации, что вообще далеко не про рядовой проект и это оптимизации вообще всего уже будут.

т.е. комбинация "прозрачность запросов генерируемых + скорость работы + api" если уж и позволяет задуматься об отказе, то в сторону plain sql

Ну, в Hibernate довольно сложная схема кэшей, которая позволяет иногда выдавать производительность выше простого использования jdbc (часть данных уже в кэшах и т.п.).  Но я-то все равно предпочитаю чистый sql, на нем точно можно сделать оптимально (например взяв jsonb вместо кучи таблиц)

Да ест-но специфичные фичи ORM не тянет, хотя бы уже select for update skip locked - просто пишешь запросы в коде. Доп. приседания в общем то присутствуют и взять чистый sql кажется наиболее прозрачным/простым. Еще бы сверху валидацию запросов в коде, но это где то недавно обсуждалось в контексте того, что решений может быть идеальных нет, но можно даже и свой тулинг написать.

В трассировках никто не смотрит запрос на языке orm, все смотрят реально ушедшие в бд запросы и пытаются сопоставить запрос в бд + запрос в коде :)

ORM не делает запросы
запросы делает слой DBAL

ORM - это слой трансформации ответов

ну, да, да, кто бы спорил, термины нужно использовать корректнее

"язык", о котором вы говорите, называется Query Builder

всё так, бью себя линейкой по рукам, ментально %)

просто сегодня чат начался с правильного употребления терминов ))

а то некоторые БД и СУБД путают и позорят гордое звание "тимлид" ))

хех)

Кстати, словарик. Вы ведете, поддерживаете в каком либо виде словарь терминов? Ну, есть, допустим, продукт в сфере страхования. В этой области и в этом контексте будет вполне ограниченный набор терминов, сущностей. Иначе быстро начинается "возьму словарь рус-англ, посмотрю прямой перевод, так и назову в коде", например. Только без "на code review провалидируем"

в вики, разумеется
а то у нас даже программисты страховых компаний любят путать термины "страхователь" и "страховщик" ))

Ну правильно я понимаю что они распиздяи раз такой инструмент написали?

приходится их поправлять ))

ubiquitous language

и ведем сразу с переводом
чтобы insurant и insurer не путали

Иногда.