Martin Fowler napisał mój ulubiony artykuł na ten temat, http://martinfowler.com/articles/evodb.html. Postanawiam nie umieszczać zrzutów schematów pod kontrolą wersji jako alumb a inni sugerują, ponieważ chcę w łatwy sposób zaktualizować moją produkcyjną bazę danych.
W przypadku aplikacji internetowej, w której będę miał pojedynczą produkcyjną instancję bazy danych, używam dwóch technik:
Skrypty aktualizacji bazy danych
Sekwencja skryptów aktualizacji bazy danych, które zawierają kod DDL niezbędny do przeniesienia schematu z wersji N do N+1. (Te znajdują się w twoim systemie kontroli wersji.) Tabela _version_history_, coś w rodzaju
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
otrzymuje nowy wpis za każdym razem, gdy uruchamiany jest skrypt aktualizacji, który odpowiada nowej wersji.
Dzięki temu łatwo jest sprawdzić, jaka wersja schematu bazy danych istnieje, a skrypty uaktualniania bazy danych są uruchamiane tylko raz. Ponownie, to nie zrzuty bazy danych. Każdy skrypt reprezentuje raczej zmiany konieczne, aby przejść z jednej wersji do następnej. Są to skrypty, które stosujesz do swojej produkcyjnej bazy danych, aby ją „uaktualnić”.
Synchronizacja piaskownicy programistów
- Skrypt do tworzenia kopii zapasowych, oczyszczania i zmniejszania produkcyjnej bazy danych. Uruchom to po każdej aktualizacji do produkcyjnej bazy danych.
- Skrypt do przywracania (i w razie potrzeby dostrajania) kopii zapasowej na stacji roboczej programisty. Każdy programista uruchamia ten skrypt po każdej aktualizacji do produkcyjnej bazy danych.
Zastrzeżenie:moje testy automatyczne działają na bazie danych zgodnej ze schematem, ale pustej, więc ta rada nie będzie idealnie odpowiadać Twoim potrzebom.
