Enkel måde for en lille virksomhed:dump din database til SQL og føj den til dit lager. Hver gang du ændrer noget, skal du tilføje ændringerne i dumpfilen.
Du kan derefter bruge diff til at se ændringer mellem versioner, for ikke at nævne have kommentarer, der forklarer dine ændringer. Dette vil også gøre dig næsten immun over for MySQL-opgraderinger.
Den ene ulempe, jeg har set ved dette, er, at du skal huske at tilføje SQL manuelt til din dumpfil. Du kan træne dig selv til altid at huske, men vær forsigtig, hvis du arbejder sammen med andre. At gå glip af en opdatering kan være en smerte senere.
Dette kan afbødes ved at lave et udførligt script til at gøre det for dig, når du underkaster dig subversion, men det er lidt meget for et enmandsshow.
Rediger: I det år, der er gået siden dette svar, har jeg været nødt til at implementere en versionsordning for MySQL for et lille team. Manuel tilføjelse af hver ændring blev set som en besværlig løsning, ligesom det blev nævnt i kommentarerne, så vi gik med at dumpe databasen og tilføje den fil til versionskontrol.
Det, vi fandt, var, at testdata endte på lossepladsen og gjorde det ret svært at finde ud af, hvad der havde ændret sig. Dette kunne løses ved kun at dumpe skemaet, men dette var umuligt for vores projekter, da vores applikationer var afhængige af visse data i databasen for at fungere. Til sidst vendte vi tilbage til manuelt at tilføje ændringer til databasedumpet.
Dette var ikke kun den enkleste løsning, men det løste også visse problemer, som nogle versioner af MySQL har med eksport/import. Normalt ville vi skulle dumpe udviklingsdatabasen, fjerne eventuelle testdata, logge indtastninger osv., fjerne/ændre visse navne hvor det er relevant og først derefter være i stand til at oprette produktionsdatabasen. Ved manuelt at tilføje ændringer kunne vi kontrollere præcis, hvad der ville ende i produktionen, lidt ad gangen, så alt i sidste ende var klar og flytningen til produktionsmiljøet var så smertefrit som muligt.