Мартин Фаулър написа любимата ми статия по темата, http://martinfowler.com/articles/evodb.html. Избирам да не поставям дъмпове на схеми под контрол на версиите като alumb и други предлагат, защото искам лесен начин да надстроя моята производствена база данни.
За уеб приложение, в което ще имам един екземпляр на производствена база данни, използвам две техники:
Скриптове за надграждане на база данни
Скриптове за надграждане на база данни с последователност, които съдържат DDL, необходими за преместване на схемата от версия N към N+1. (Те влизат във вашата система за контрол на версиите.) Таблица _version_history_, нещо като
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
получава нов запис всеки път, когато се изпълнява скрипт за надстройка, който съответства на новата версия.
Това гарантира, че е лесно да се види каква версия на схемата на базата данни съществува и че скриптовете за надграждане на базата данни се изпълняват само веднъж. Отново, това сане дъмпове на база данни. По-скоро всеки скрипт представлява промените е необходимо да преминете от една версия към друга. Те са скриптът, който прилагате към вашата производствена база данни, за да я „надстроите“.
Синхронизиране на пясъчна среда за програмисти
- Скрипт за архивиране, дезинфекция и свиване на производствена база данни. Изпълнявайте това след всяка надстройка до производствената БД.
- Скрипт за възстановяване (и настройване, ако е необходимо) на архива на работната станция на разработчика. Всеки разработчик изпълнява този скрипт след всяко надграждане до производствената БД.
Предупреждение:Моите автоматизирани тестове се изпълняват срещу правилна схема, но празна база данни, така че този съвет няма да отговаря напълно на вашите нужди.
