Jak zmieniasz / śledzisz zmiany w tabelach SQL?

Pracując w zespole programistów, w którym wszyscy wprowadzają zmiany w tabelach lokalnych i tabelach programistycznych, w jaki sposób zachować synchronizację wszystkich zmian? Centralny plik dziennika, w którym każdy przechowuje zmiany SQL? Strona wiki służąca do śledzenia instrukcji zmiany tabeli, pojedynczych plików .sql, które deweloperzy mogą uruchomić, aby zaktualizować lokalne bazy danych do najnowszej wersji? Użyłem niektórych z tych rozwiązań i staram się uzyskać dobre, solidne rozwiązanie, które działa, więc doceniam twoje pomysły.

Korzystam z opartego na kodzie narzędzia do migracji bazy danych i trzymam kod migracji pod kontrolą źródła.

Używając znaczników czasowych jako numerów wersji, dowolna liczba programistów może w większości dowolnie dodawać migracje, a my możemy uruchomić narzędzie Migracja z dowolną kopią naszej bazy danych.

Kiedyś używałem skryptów SQL pod kontrolą wersji, ale uważam, że podejście oparte na kodzie jest o wiele łatwiejsze do pracy, ponieważ wszystkie znajdują się w jednym logicznym „miejscu” i są w stanie wykonać wszystkie potrzebne skrypty za pomocą jednego polecenia.

Nie robię tego sam, ale niektórzy programiści utrzymują kolekcję skryptów SQL pod kontrolą źródła, która po uruchomieniu może odtworzyć tabele bazy danych do celów testowych i zbudować pustą bazę danych do celów produkcyjnych.

Tej samej techniki można użyć do wersji bazy danych w witrynie klienta, gdy pola lub tabele muszą zostać dodane lub usunięte, lub transformacje danych muszą mieć miejsce.

Twórz skrypty pod kontrolą wersji i ciągłą integracją, aby je weryfikować

Jednym ze sposobów, które działało dla mnie, było umożliwienie każdemu programistowi pracy z własnym schematem, z którym mogą robić to, co lubią. Ich schemat był możliwy do zniszczenia i wypełniony danymi testowymi pobranymi z zestawu skryptów kontrolowanych wersjami, do którego wszyscy twórcy się przyczynili.

Nocna kompilacja ciągłej integracji wzięła najnowszą wersję wszystkich skryptów i próbowała zbudować z nich spójną testową bazę danych. Następnie aplikacja przeprowadziła szereg testów integracyjnych i funkcjonalnych, aby sprawdzić, czy bieżący schemat jest zgodny z bieżącym kandydatem do wydania.

Przed rozpoczęciem tej drogi istniała dość solidna konstrukcja bazy danych, a DBA zawsze pilnował rzeczy, aby uniemożliwić programistom szaleństwo z powodu denormalizacji i innych okropności.

Kontrola wersji bardzo pomogła tutaj, ponieważ zmiany w skryptach były natychmiast widoczne. Wykorzystaliśmy również VERSIONtabelę bazy danych, aby określić ogólny stan bazy danych. To była prosta sekwencja liczb całkowitych i nie była powiązana z żadną konkretną aplikacją.

Ogólnie rzecz biorąc, działało dobrze i oznaczało, że programiści przestali się obawiać zmiany poziomów trwałości, ponieważ zawsze mogli wycofać swoje własne schematy bez wpływu na inne.

Jeśli jesteś w sklepie MS, Visual Studio 2010 ma kilka fajnych narzędzi kontroli wersji bazy danych, które mogą również generować skrypty zmiany / wdrażania na podstawie różnic między dwiema bazami danych.

Oprócz utrzymywania schematów i innych skryptów SQL pod kontrolą wersji, inną przydatną praktyką jest utrzymywanie tabeli „wersji schematu” w rzeczywistej bazie danych .

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

Doctrine ma niesamowite narzędzie do migracji: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations , najlepsze jest to, że są one generowane automatycznie lub można je łatwo kodować ręcznie.

Podejście, którego używam, to zapewnienie jednej tabeli parametrów. Ta tabela będzie zawierała jedną parę nazwa / wartość dla wersji, w której znajduje się baza danych. Daje mi to dwie korzyści: Mam sposób na zweryfikowanie, czy aplikacja poprawiła tylko bazę danych i mogę użyć tej wartości w moich skryptach SQL.

Skrypt SQL utworzy nowe tabele, zmieni kolumny i wszelkie inne prace związane z bazą danych w celu wypromowania skryptu z poprzedniej wersji. Idealnie byłoby też mieć skrypt wycofywania, ale przez większość czasu nie.

BTW, całe to podejście zostało zautomatyzowane w ramach Ruby on Rails, wraz ze skryptami wycofywania. Podoba mi się to, ale nie wszystkie ramy to robią. Kiedy nie używam Ruby on Rails, używam podejścia opisanego powyżej.