Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

Здравствуйте, vladpol, Вы писали:

V>Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

Саксес стори именно в том варианте что ты описал.
Посмотри на https://www.red-gate.com/products/sql-development/sql-compare/
Готовые тулзы они только для схемы, данные мигрировать придется самому

Здравствуйте, vladpol, Вы писали:

V>Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

У джавы есть liquibase и flyway у питона есть django. Видел сакксес стори на этих трех.
Еще видел саксес стори с самодельной тулзой, даже круче вышеперечисленных была. Если нет хранимых процедур то все просто вобщем-то.

Лично я ни разу не видел фирменной тулзы для апгрейда базы с данными. Успешно пользовались самописными. Если нет логики в БД и изменения структуры не сильные, то да, можно использовать что-то типа django. Если есть процедуры-вьюхи и структура меняется, то мы делали свою тулзу. Вполне успешно.
И еще, по поводу хранить в базе номер изщменения и его потом анализировать — это путь тяжелый. Особенно если клиентов много и не все они у себя строго обновляют версии до последней. Я даже не говорю про вариант, что они в БД залезли и что-то там поменяли.

Здравствуйте, vladpol, Вы писали:

V>Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

Если используется какой-нибудь ORM вроде Entity Framework, то он сам при соответствующих настройках обновит структуру таблиц в БД при запуске. Но лично я таким никогда не пользовался, все подобные виды автоматизации отключаю. Вместо этого скрипт модификации пишу всегда так, чтобы его можно было прогонять сколько угодно раз, и он догонял базу до последней версии. Никакой "текущей" версии хранить не надо ни в скрипте, ни в базе. Работает всегда, исключения составляют редкие массовые изменения данных в БД.

Здравствуйте, vladpol, Вы писали:

V>Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

Если у вас Microsoft SQL Server, то можете попробовать SQL Server Data Tools deployment. Позволяет накатить схему БД до нужной версии + есть возможность более тонкой настройки с помощью пре- и пост-деплоймент скриптов.

На нашем проекте перешли уже года четыре назад, как раз с ручных апдейт скриптов. В разы удобней

Здравствуйте, vladpol, Вы писали:

V>Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

Чуть более продвинутый вариант — писать апдейт-скрипты вручную (на SQL) или, например для .net, на "птичьем языке" (типа EF Migration или Fluent Migrator) и хранить в базе "номера" ВСЕХ примененных.

Здравствуйте, vladpol, Вы писали:

V>Приветствую кого-то есть success story  поддержки версионости БД. чтобы инсталятор новой версии без проблем дотягивал БД до нужного состояния? Самый ходовой вариант, — писать апдейт- скрипты вручную и хранить в базе номер последнего. Но может быть есть что-то по продвинутей

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