Контроль версий БД

← →
StriderMan (2009-03-18 18:03) [0]

Вопрос конечно боянистый, но все же, поделитесь технологиями.

Для проектов внутри конторы пользуемся VSS *. Умею и SVN.

Эталонная база данных (FIREBIRD) лежит на сервачке и туда просто вносят изменения периодически. Ну бэкапится, как положено конечно. Но хотелось бы управлять БД аналогично исходникам. В принципе достаточно метаданных.

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

Кто чем пользуется?

* - для ярых противников VSS. Для разработки внутри отдела небольшим числом программеров считаю его удобнее и проще чем SVN.

← →
clickmaker © (2009-03-18 18:30) [1]

мы долго думали всем колхозом, но так ничего лучше скриптов не придумали... С историей накатов в отдельном файле.
а почему так уж неудобно?
change-скрипты можно привязывать к задачам. Если совсем примитивно - раскладывать по папкам с номером бага в каком-нибудь тесттрэке.

← →
b z (2009-03-18 18:43) [2]

> Но хотелось бы управлять БД аналогично исходникам.
А у вас, у каждого, по отдельной рабочей базе?

← →
StriderMan (2009-03-18 19:16) [3]

> А у вас, у каждого, по отдельной рабочей базе?

да, есть у каждого своя + одна общая эталонная.

Чтобы получить последние изменения из эталонной в свою пользуемся Database Comparer"ом из IBExpert

> С историей накатов в отдельном файле.

А как тогда пользоваться удобными средствами разработки БД типа IBExpert? надо полазить, мож. там историю можно вытянуть...

← →
clickmaker © (2009-03-18 19:32) [4]

> А как тогда пользоваться удобными средствами разработки
> БД типа IBExpert?

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

← →
StriderMan (2009-03-18 20:57) [5]

> Потом они собираются в одном месте и при очередном обновлении
> накатываются на базы

А собираются в одном месте они автоматически или разработчик добавляет?

> Причем, накатываются сначала на тестовую - это может делать
> сам программист - потом тестируются, потом уже на рабочую

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

← →
Ega23 © (2009-03-19 10:22) [6]

> но так ничего лучше скриптов не придумали...

Аналогично.

← →
Медвежонок Пятачок © (2009-03-19 10:29) [7]

Делаю проще.
При старте приложения вызвается CheckDBStruct;
И если новой версии требуются новые объекты, то например
if not CheckTableExists() then CreateTable() else CheckTableStruct()

То есть DDL выполняет само ПО.
Ну и скрипты конечно все равно есть.

← →
Ega23 © (2009-03-19 10:44) [8]

> Делаю проще.

Насчёт "проще" - это очень спорный вопрос.
И потом, чтобы создавать объекты, нужно соответствующий grant иметь.

← →
Медвежонок Пятачок © (2009-03-19 10:49) [9]

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

← →
b z (2009-03-19 10:59) [10]

> StriderMan (18.03.09 19:16) [3]
> да, есть у каждого своя + одна общая эталонная.
А смысл в этом? Я вот искренне не понимаю зачем вся эта чехорда с базами нужна, почему-бы не разрабатывать на одной рабочей, т.к. на сколько я понял нет удаленки впринципе, там еще понятно, а тут? Этож сколько надо усилий по синхронизации (мержинга), необходимость в данном случае которого сомнительна. Тем более работая с VSS, который по сути "пессимистик" ...

← →
ЮЮ © (2009-03-19 11:08) [11]

1) из SVN репозитория делается ChekOut метаданных
2) данные удаляются
3) утилитой, умеющей генерировать методанные, они создаются из актуальной БД
3) делаем SVN Commit и видим все изменения. У нас они делаются не скопом, а по проблемам, поставленныв в баг-чеккере, авторами изменений после решения бага/проблемы

← →
StriderMan (2009-03-19 11:46) [12]

> А смысл в этом? Я вот искренне не понимаю зачем вся эта
> чехорда с базами нужна, почему-бы не разрабатывать на одной
> рабочей, т.к. на сколько я понял нет удаленки впринципе,
> там еще понятно, а тут

У каждого своя рабочая, чтобы безопасно для техпроцесса можно было на ней крутить и ворочать структуру, отлаживать код. После отладки метаданные тем или иным способом накатываются на эталонную базу.
Проблема в том чтобы отследить кто когда и что туда накатывал, чтобы знать кому надавать по щщам если что :)

ЮЮ © (19.03.09 11:08) [11]
к такому варианту и склоняюсь. Тут видится пара минусов:
1. каждый раз перед Check-In (=svn commit) надо снимать метаданные. Недолго но нудно.
2. В VSS при check-out для других файлик будет залочен, т.е. одновременно базу править не получится. В SVN такой проблемы не будет, однако будут постоянные конфликты версий, требующие разруливания.
Да и на SVN переходить не хотим. Обязательные блокировки VSS надежнее, когда все программеры сидят в одной комнате и получают в тык за неотпущенные файлы.

Вот пришла идея раскидать весь скрипт с метаданными по отдельным файлам, представляющим объекты БД. Что скажете?

← →
ЮЮ © (2009-03-19 11:56) [13]

> Вот пришла идея раскидать весь скрипт с метаданными по отдельным
> файлам, представляющим объекты БД. Что скажете?

У нас, например, так и есть.

← →
StriderMan (2009-03-19 12:03) [14]

> У нас, например, так и есть.

А как из них базу собираете? Надо ведь в правильном порядке проиграть серверу

А мы её не разбираем :)

Нас интересует контроль версий: кем, когда и как изменился какой либо объкт БД.

А апграйд базы от одной версии до другой - это уже другая задача. Когда-то даже решалась. Но кода база одна и на корпоративном сервере - давно остыл к этй проблеме интерес :)

← →
StriderMan (2009-03-19 12:14) [16]

> А мы её не разбираем :)

А не возникает рассинхронизация метаданных в файликах и реальной базы? Ведь если кто-то поленится и ручками че-то подправит это нигде не отразится?

> А не возникает рассинхронизация метаданных в файликах и
> реальной базы? Ведь если кто-то поленится и ручками че-то
> подправит это нигде не отразится?

Естественно временами случается. Но процедура из [11] выполняется всеми над всеми объектами базы, а за незалитые в SVN изменения нагоняи имеют место :)

← →
b z (2009-03-19 13:13) [18]

> StriderMan (19.03.09 11:46) [12]
> У каждого своя рабочая, чтобы безопасно для техпроцесса
> можно было на ней крутить и ворочать структуру, отлаживать код.
Т.е. код синхронизировали vss-ом, и тестируем на несинхронизированной базе? странно все это...

> чтобы знать кому надавать по щщам если что :)
Увеличением количества баз это врядли решается, а нооборт, я бы сказал, усугубиться должно.
Отдайте эту проблему cvs-у.
А от "человеческого фактора" ничего не поможет, тут я согласен с ЮЮ ©, только "палка". ;) Есть еще всякие программы для сравнения структур и синхронизации, не знаю про FIREBIRD, для MS SQL Server и Oracle видел и пользовались.

← →
StriderMan (2009-03-19 14:12) [19]

> Т.е. код синхронизировали vss-ом, и тестируем на несинхронизированной базе? странно все это...

> Есть еще всякие программы для сравнения структур и синхронизации,
> не знаю про FIREBIRD, для MS SQL Server и Oracle видел
> и пользовались

знаем, юзаем
> Чтобы получить последние изменения из эталонной в свою пользуемся Database Comparer"ом из IBExpert

Контроль версий БД Найти похожие ветки