Получите мою базу данных при Управлении версиями с помощью [Подвижного] DVCS
Каков был бы лучший подход для управления версиями моя целая база данных?
Создавая файл для каждого объекта базы данных (таблица, представление, procedsure..) или довольно имеющий один файл для всех сценариев DDL и какого-либо нового изменения будет помещен в отдельный файл?
Что относительно того, чтобы обработать изменения сделан в инструменте Менеджера базы данных?
Я хотел бы иметь дженерик решения для любого вида RDBMS.
Есть ли какие-либо другие опции?
3 ответа
Если вам нужно универсальное решение - запишите все в скрипты (простые текстовые файлы) и поместите под систему контроля версий (можно использовать любую VCS).
Группировка схожих объектов базы данных в скрипты будет зависеть от ваших требований.
Например, вы можете:
Хранить таблицы/индексы/ в одном или нескольких скриптах. Каждую процедуру хранить в отдельном скрипте или объединить несколько процедур в один скрипт.
Однако при таком подходе необходимо помнить одну важную вещь: не забывайте менять скрипты, если вы изменили таблицу/представление/процедуру непосредственно в базе данных, и не создавайте/восстанавливайте/компилируйте объекты db в базе данных после изменения скриптов.
Я большой поклонник VCS в целом и большой бустер Mercurial, но я действительно думаю, что вы идете по неправильному пути.
VCS - это не только итеративные изменения, «что», они также отвечают на вопросы «кто», «когда» и «почему». Для базы данных эти ответы намного менее интересны или трудны для предоставления VCS. Если вы выполняете ночной экспорт и фиксируете «who», всегда будет «cron», а «почему» всегда будет «midnight».
Еще одна вещь, которую современные VCS действительно хорошо делают, - это помощь в слиянии изменений из нескольких веток. Это менее применимо в мире баз данных. Очень редко вы говорите: «Мне нужна эта структура таблицы, но эти данные», и если вы сделаете слияние текста / различий, вам не очень поможет.
То, что делает «что» и «когда» очень хорошо, - это система инкрементного резервного копирования, и это, вероятно, лучше всего подходит.
На работе мы используем Tivoli, а дома я использую rdiff-backup и duplicity, но есть много отличных вариантов.
Я полагаю, что мое общее эмпирическое правило таково: «если он был напечатан вручную человеком, то он попадает в систему управления версиями, а если он был сгенерирован / экспортирован, то он попадает в инкрементные резервные копии»
Конечно, вы можете сделать эта работа, но я не думаю, что она принесет вам большую выгоду по сравнению с более традиционными решениями для резервного копирования.