Научить - это хороший вариант. Но тогда адище начинается когда в исходниках смешиваются "хороший SQL" и "хорошая java". И рождается очередной ниндзя.

Чтоб была понятна позиция - я за понятные рамки применимости. Без упора в идеологию.

Ну, у меня обычно простой SQL и простая Java. Да, это простота требует хорошей подготовки (

балбесов хватало))))

Ну то есть опять орг.проблемы решали техническими методами. Эххх.

Простой SQL эт чот типа рекурсивных запросов обхода графов?

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

В go все драйверы такие

Но я вот уже очень давно не встречал необходимости в реально сложной работе с БД.

Э, мне вот интересно, а как они это делают по работе с тем же PG. Там же все равно приходится привязывать соединение к корутине и пока транзакцию не закрыли - передавать нельзя. Так что производительность не изменится

там пул, да

Построение иерархий действительно лучше работает в графовой БД, и скорее всего от РСУБД мы туда все рано или поздно уползём.
Однако подхода это не меняет ИМХО. Хорошие SQL к графовым БД упакованные в правильные обёртки как раз позволят избежать неправомерного и кривого изменения конститентности данных.

Например построить и вернуть иерархию - вполне себе задачка для хранимки.
Вставить объект в иерархию - тоже.
Обновить объект иерархии - тоже.

А вот история про реализацию "как менять и зачем" - там я считаю неуместным.

Ну, всюду пул. Но тогда нет разницы между корутинами и тредами в данном сценарии.
Все равно реально с БД работает немного потоков, остальные ждут, пока им из пула выдадут.
Понятно, что ждать в корутине дешевле, чем в треде, но в данном случае это не очень существенно.

Ну да, я такое тоже обычно делал или хранимками или базовыми процедурами в той же java, которые вызывались остальными разработчиками. Главное - не приводить к тому, что подобные запросы все будут писать сами в меру своего понимания.

Именно поэтому я говорю про ответственного за БД специального разраба, который бы это понимание бы обеспечивал для команды как компетенцию.

я б ещё технолога по реляционной модели зарядил

Ну ER обычно аналитик делает.

чтоб реально проектировал с учётом структурированных выборок типа деревьев

когда селф реверенсд строки есть где нужно грамотно ссылочные таблицы приколхозить

да и ещё треш с оконными функциями ни кто не отменял, джависты мои боятся туда лазить от слова совсем

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