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

Это попытка хоть как-то оправдать использование. Бест практисес: не делайте так пожалуйста

у меня целый набор гипотиз есть как некоторые фичи ORM приводят к отсутствию скила декомпозиции стэйта у разработчиков. Оч много и оч долго приходится их переучивать

в таком случае бекендеры не нужны, только дба-шники.

А какие там костыли в том же spring jdbc templates? Гораздо прямее, чем в JPA.
Если постоянно структура меняется, то в JPA совсем грустно станет (

Это тот стартап, что хочет помогать всем командам, но еще сам не знает как и для чего?

Эээ, а если схема меняется в результате миграции - как оно будет работать?
Вообще умение сервиса работать с двумя версиями схемы БД одновременно - одно из базовых требований для сколь-нибудь разумного деплоя.

Ребят, всем спасибо. Остановлюсь на том, что сейчас использую jdbc templates. Просто сейчас мапинги из селектов, инсерты и апдейты написаны на рефлексии и мне это кажется костылем

в общем виде такое не реализуется принципиально, две версии базы могут отличаться драстически

стратегии деплоймента с zero downtime это отдельная тема, но скажем если мы добавляем новое поле в таблицу - это просто
сначала накатывается апдейт на существующие данные, добавляя это поле везде с дефолтным значением, а потом апдейтим сервис

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

В общем случае - да, проблемы. Но частные варианты в
очень гибкие бывают. Ну и полезно в любой записи хранить по какой она схеме сохранена )

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

всё там нормально работает с миграцией без даунтайма. ну, да, может в несколько подходов.

конечно, это слишком скучно. надо завести макс. кол-во модных технологий к месту и нет) эвентсорсинг, даталейк и т.д.

с реляционными базами "всё нормально работает" до определённых пределов
если в реляционной таблице миллиарды записей, то схему менять вообще нельзя, alter table будет выполняться пару суток

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

Ну, нет. add column null мгновенная.

Тут тоже беда - нужно поддерживать кучу старых форматов для таких преобразований, что и дорого и сложно и не всегда реально (есои там обогащение потребуется)

ну, зависит от базы, оракл ещё 20 лет назад умел делать неблокирующий DDL

Кстати, как раз нет. У него была бага в парсере, из-зв чего формально безопасный alter table null начинал таки вставлять значения. Я эти два часа простоя до сих пор помню

Впрочем, в Оракле баги вообще повсюду (были - точно, последние лет семь с ним не работаю).