Я так понимаю что flyway и liquibase юзают тока джуны тогда

блять, они на мускуле пишут

забей

И db-per-tenant, схема для сырых клиентских данных, поступающих с кучи машин и их последующей аналитики. Данных много, данные разные, связаны друг с другом в хитрых вариациях, таблиц там много, все с кучей колонок. Когда тенант дорастает до 10 GB - мы подчищаем старые данные (своего рода round-robin). Но это слишком сложно для мальчика, который хочет CREATE TABLE руками писать.

лиза смотри какой сложный проект

Не поняла как это связано

мальчик ниасилит

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

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

пишу create table руками, брат жив

а еще в коде иногда есть sql, пушо хз как через орм делать left merge join

Напрямую: если мы ещё и нововведения в эту схему будем руками херачить (как происходит собсно сейчас), то мы собсно половину времени будем тратить на то, чтобы разобраться куда же по констрейнтам приткнуть новую таблицу так, чтобы ничего не поломать. А если машина будет валидировать сопоставление схемы и кода НУ ХОТЬ КАК-ТО и генерить нам, скажем 70% от той портянки DDL-я, который надо накатить на базу при апдейте - это сильно нам сэкономит время. Можно конечно нанять @zawodskoj за три копейки - будет нам херачаить CREATE TABLE-ы руками, но нам не очень хочется иметь дело с джунами.

у тебя денег не хватит чтоб меня нанять

не ну это бан

че он хамит

можешь нанять меня в ипотеку

Он первый начал

В смысле приткнуть? То есть тебе типа еф решает вопрос валидации констрейнтов или что?

ыыы первый начал

И 30% все равно ручного скля пишется?