Prosty sposób dla małej firmy:zrzuć swoją bazę danych do SQL i dodaj ją do swojego repozytorium. Następnie za każdym razem, gdy coś zmienisz, dodaj zmiany w pliku zrzutu.
Następnie możesz użyć diff, aby zobaczyć zmiany między wersjami, nie wspominając o komentarzach wyjaśniających twoje zmiany. Dzięki temu będziesz praktycznie odporny na aktualizacje MySQL.
Jedyną wadą, którą widziałem, jest to, że musisz pamiętać o ręcznym dodaniu kodu SQL do pliku zrzutu. Możesz nauczyć się, aby zawsze pamiętać, ale bądź ostrożny, jeśli pracujesz z innymi. Brak aktualizacji może być później uciążliwy.
Można to złagodzić, tworząc skomplikowany skrypt, który zrobi to za ciebie podczas zgłaszania się do subversion, ale to trochę za dużo jak na jednoosobowy pokaz.
Edytuj: W roku, który minął od tej odpowiedzi, musiałem zaimplementować schemat wersjonowania MySQL dla małego zespołu. Ręczne dodawanie każdej zmiany było postrzegane jako kłopotliwe rozwiązanie, podobnie jak wspomniano w komentarzach, więc zdecydowaliśmy się na zrzucenie bazy danych i dodanie tego pliku do kontroli wersji.
Odkryliśmy, że dane testowe trafiały do zrzutu i utrudniało ustalenie, co się zmieniło. Można to rozwiązać poprzez zrzucenie samego schematu, ale było to niemożliwe dla naszych projektów, ponieważ nasze aplikacje były zależne od pewnych danych w bazie danych, aby funkcjonować. W końcu wróciliśmy do ręcznego dodawania zmian do zrzutu bazy danych.
Było to nie tylko najprostsze rozwiązanie, ale także rozwiązało pewne problemy, które niektóre wersje MySQL mają z eksportem/importem. Normalnie musielibyśmy zrzucić rozwojową bazę danych, usunąć wszelkie dane testowe, wpisy w dzienniku itp., usunąć/zmienić niektóre nazwy tam, gdzie ma to zastosowanie, i dopiero wtedy móc utworzyć produkcyjną bazę danych. Dzięki ręcznemu dodawaniu zmian mogliśmy dokładnie kontrolować, co trafi do produkcji, po trochu, tak aby w końcu wszystko było gotowe, a przejście do środowiska produkcyjnego było tak bezbolesne, jak to tylko możliwe.
