Wersja bazy danych / kontrola zmiany danych, a nie schemat?

Po przeczytaniu kilku artykułów tutaj i wokół, zdałem sobie sprawę, że kontrola wersji bazy danych w zespole programistów ma duże znaczenie.

Do tej pory korzystałem z prostegodump whole database za każdym razem, gdy jest aktualizacja, jeśli tylko jedna tabela została zmieniona, czasami możemy uciec, po prostu wyrzucając pojedynczą tabelę, a następnie reimportując. Nie najlepiej, ale działa całkiem dobrze, na zmiany addytywne i nie mieliśmy jeszcze żadnych problemów.

Teraz oszczędzam.mwb (Mysql Workbench diagram) plik w repozytorium git projektu, nad którym pracuję. Wtedy też używamdbv dlaschema management, wraz z git, przy czym każda gałąź jest nazywana na podstawie projektu i działa całkiem dobrze. To pozwala mi na zmianę schematu zmian z możliwością przywrócenia lub wycofania.

Co jednak z danymi zawartymi w tabelach. Jak można to utrzymać? Może lepiej po prostu trzymać się starej metody. Rozumiem w projektach o tej samej strukturze DB, ale różnych danych, co jest w porządku, ale co z witrynami z konkretnymi danymi bazy danych, które muszą być wersjonowane i zarządzane.

A co z bazą już wdrożonych witryn, które wymagają zmian w bazie danych, jak to może być bezproblemowe. Niektórzy sugerują użycie skryptów aktualizacji / modyfikacji i działa to dobrze z wartościami domyślnymi i takimi. Co jednak zrobić, jeśli dokonałem zmiany na platformie internetowej, która wymaga zmiany bazy danych każdej witryny i zachowania danych w stanie nienaruszonym?

questionAnswers(2)

yourAnswerToTheQuestion