Речь о http(окей, там fastcgi, если говорить о php-fpm). Смысл в том, что воркеров там фиксированное количество(равное размеру пула) и воркер просто "висит", пока ждёт ответа от бд или внешнего ресурса.

В языке с корутинами/green threads мы бы переключились и поделали что-то полезное.

Как мне рассказывали, для PHP уже есть реактивные фреймворки.
Впрочем, что корутины, что реактивка очень плохо сочетаются с РСУБД и дело там не в языке (

Я до сих пор не понимаю проблемы, зачем абстрагировать приложение от БД.
БД мы что, каждый день меняем?
Разработчик бэкенда, не понимающий как устроены БД, как пишется SQL, скорее всего не умеет проектировать структуры данных. Нам зачем такой нужен? Ну разве что формы верстать.

Больше запросов => больше запросов встаёт в очередь(чтобы исполнится каким-то воркером) => больше время ответа

угу, к сожалению, большинство забыли что "алгоритмы + структуры данных = программы"

Есть, но это отдельный, особенный мир. Де-факто так никто не делает.

Почему плохо сочетаются?

В .NET первые придумали ключевые слова async / await, очень удобно для развязывания асинхронного и синхронного кода

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

Ну, там все равно проблемы остаются, увы.
Если бы можно было работать без понятия соединения, то было бы проще.
Больше всего без с JDBC, который сильно завязан на ThreadLocal (

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

Стоимость поддержки ниже за счёт разделения ответственности и соответственно упрощения анализа внесения изменений. Не?

А где ты такой драйвер найдешь, для каких БД он есть?
Пока я знаю только про реактивный для PG, но он очень плох.

Всё проще, по сути 2 проблемы. 1. Сиквел текстом в джава тяжело проходил аудит безопасности, очень часто разрабы банально пользовали литералы вместо переменных, код ревью на этот предмет занимал ресурсы. 2. Отсутсвие состояния в деве аналогичное прому на нагрузочных тестах, особенно в части дедлоков на апдейтах, разраб просто не в состоянии предусмотреть \ разработать механизм сериализации тх, потому что состояние не детерменированное. Существенно усложняется работа с пулами соединений и с предкомпелированными запросами.

Не. Если только вы умеете вносить изменения в БД, не внося их в приложение.

Хм, при разделении ответственности стоимость скорее растет, разве нет?

Конечно умею, для этого API и делается в виде инкапсулирующих логику хранения (CRUD) процедур.

А ТТМ снижается.

БЛ в хранимках БД? Вопросов больше не имею 😊

Утомил. Рили. Где я про БЛ в БД писал?)