W jaki sposób grupa może śledzić schemat bazy danych?

Jakie metody kontroli wersji pomagają zespołom ludzi śledzić zmiany schematu bazy danych?

zaledwie kilka minut temu sprawdzałem to: tabela, która powinna istnieć we wszystkich projektach z bazą danych , wydaje się dość prosta do zastosowania w praktyce, sprawdź to:

Nazywa się to schema_version (lub migracje lub cokolwiek, co Ci odpowiada), a jego celem jest śledzenie zmian strukturalnych lub danych w bazie danych. Możliwą strukturą (przykład w MySQL) jest:

create table schema_version (
     `when` timestamp not null default CURRENT_TIMESTAMP,
     `key` varchar(256) not null,
     `extra` varchar(256),
     primary key (`key`)
) ENGINE=InnoDB;

wstaw do wartości schema_version ( key, extra) („001”, „wersja schematu”);

Niezależnie od tego, czy dodasz tę tabelę od początku projektu, czy zaraz po wdrożeniu pierwszej wersji na serwerze pomostowym lub produkcyjnym, zależy od Ciebie.

Ilekroć trzeba wykonać skrypt SQL, aby zmienić strukturę bazy danych lub przeprowadzić migrację danych, należy również dodać wiersz w tej tabeli. I zrób to za pomocą instrukcji insert na początku lub na końcu tego skryptu (który jest przypisany do repozytorium kodu projektu).

…

Myślę, że najlepszą metodą jest wygenerowanie bazy danych w ramach procesu kompilacji . Trzymaj wszystkie skrypty pod kontrolą źródła wraz z resztą kodu, a każdy jest odpowiedzialny za własne środowisko.

W przeciwnym razie RedGate ma narzędzie do zintegrowania kontroli źródła z SSMS, a porównywanie SQL jest przydatne do porównywania / synchronizacji schematów MS SQL Server. Program Visual Studio Database Edition ma również wbudowane narzędzie do porównywania schematów .

Kolejne SO pytanie zaprowadziło mnie do Migrator Dot Net, które zamierzam rozpocząć w czasie mojego wolnego czasu. Wygląda to na dobrą metodę, ale może być bardziej czasochłonną / kosztowną inwestycją, niż jesteś skłonny poczynić.

eiefai już wspomniał Tabela, która powinna istnieć we wszystkich projektach z bazą danych . To świetny post na blogu, ale IMO stanowi tylko część drogi do działającego rozwiązania do kontroli wersji bazy danych. Myślę, że każda próba „odpowiedzi” na to pytanie w realnym świecie wymaga uwzględnienia niektórych innych informacji o VCS i bazach danych:

• Metodologia Agile Data
• Książka „Refaktoryzacja bazy danych”
• Artykuł Martina Fowlera na temat „Evolutionary Database Design”
• Narzędzie Liquibase
• Przyzwoite wideo ze Scottem Amblerem przedstawiającym swoje przemyślenia na temat „Agile Databases”

Sądzę, że istnieje kilka różnych punktów widzenia, aby podejść do tego pytania. Uważam, że kąt „pierwsze narzędzie” będzie się różnić w zależności od platformy i osobistych preferencji. Przykład: korzystam z projektu bazy danych w MS Visual Studio, ale nie jestem pewien, czy jest to świetne rozwiązanie dla MySQL. Znam również ludzi, którzy są sprzedawani na swoich ulubionych narzędziach od Redgate, Erwin, Embarcadero itp.

Istnieje również „pierwszy proces” dla tego pytania, które (miejmy nadzieję) zostanie ponownie omówione na tej stronie w kolejnych pytaniach. Najważniejsze w tym procesie jest kontrolowanie schematu i zarządzanie zmianami, dzięki czemu można zastosować zmiany schematu z wersji „x” do wersji „y” praktycznie na żądanie.

Ostateczna odpowiedź na ten temat będzie wyglądać jak książka, więc prawdopodobnie warto zacząć od odwołania się do jednego z nich: Redgate niedawno opublikował darmowy ebook o nazwie „ Przewodnik po bramce Red Development dotyczący tworzenia zespołowego programu SQL Server ” i chociaż istnieje jest wiele do dyskusji, to całkiem dobre miejsce do rozpoczęcia dyskusji, IMO. Wbrew nazwie, duża część materiału w tej książce jest na tyle ogólna, że ​​można ją zastosować do dowolnej bazy danych (nie tylko SQL Server) i dowolnego zestawu narzędzi (nie tylko Redgate). Jeśli jeszcze tego nie widziałeś, zdecydowanie warto to przejrzeć.

Wreszcie, prawdopodobnie warto połączyć w „starszej odpowiedzi” z przepełnienia stosu .

SchemaCrawler to moje narzędzie do tworzenia pliku tekstowego ze wszystkimi obiektami schematu bazy danych. Zaprojektowałem ten tekst wyjściowy tak, aby był czytelny dla człowieka, a także odróżniał się od podobnych wyników z innego serwera.

W praktyce odkryłem, że wyjście pliku tekstowego schematu bazy danych jest przydatne, gdy jest wykonywane jako część kompilacji. W ten sposób możesz sprawdzić plik tekstowy w systemie kontroli kodu źródłowego i mieć historię wersji, w której ewoluował twój schemat. SchemaCrawler jest również zaprojektowany do automatyzacji tego z poziomu wiersza poleceń.