Mechanismen voor het bijhouden van DB schema veranderingen

stemmen
128

Wat zijn de beste methoden voor het volgen en / of het automatiseren van DB schema veranderingen? Ons team maakt gebruik van Subversion voor versiebeheer en we zijn in staat om een ​​aantal van onze taken te automatiseren zo geweest (duwen opbouwt naar een testserver, implementeren getest code om een ​​productie-server), maar we zijn nog steeds updates van de database handmatig te doen. Ik wil graag weten of maak een oplossing die ons in staat stelt om efficiënt te werken aan de overkant van servers met verschillende omgevingen terwijl het voortdurend om Subversion te gebruiken als een backend waardoor code en DB updates rond worden geduwd naar verschillende servers.

Veel populaire software pakketten bevatten auto-update scripts die DB-versie detecteren en de noodzakelijke wijzigingen toe te passen. Is dit de beste manier om dit te doen, zelfs op grotere schaal (in meerdere projecten en soms meerdere omgevingen en talen)? Zo ja, is er een bestaande code die er zijn dat het proces vereenvoudigt of is het best alleen om onze eigen oplossing te rollen? Heeft iemand iets dergelijks uitgevoerd voor en geïntegreerd in Subversion post-commit haken, of is dit een slecht idee?

Terwijl een oplossing die meerdere platforms ondersteunt de voorkeur zou verdienen, zeker moeten we de Linux / Apache / MySQL / PHP stack ondersteuning van de meerderheid van ons werk is op dat platform.

De vraag is gesteld op 04/08/2008 om 22:31
bron van user
In andere talen...                            


20 antwoorden

stemmen
54

In de Rails wereld, is er het concept van de migraties, scripts waarin veranderingen aan de database zijn gemaakt in Ruby in plaats van een database-specifieke smaak van SQL. Uw Ruby migratie code uiteindelijk wordt omgezet in de DDL specifiek zijn voor uw huidige database; dit maakt het schakelen databaseplatforms zeer eenvoudig.

Voor elke wijziging die u maakt met de database, je schrijft een nieuwe migratie. Migraties hebben meestal twee methoden: Een "up" methode waarbij de veranderingen worden aangebracht en een "down" werkwijze waarbij de veranderingen ongedaan gemaakt. Een enkel commando brengt de database up-to-date, en kan ook worden gebruikt om de database naar een specifieke versie van het schema te brengen. In Rails, zijn migraties in hun eigen directory in het project directory gehouden en krijgen ingecheckt in de versie controle, net als elk ander project code.

Dit Oracle gids voor Rails migraties dekt migraties heel goed.

Ontwikkelaars gebruik van andere talen hebben gekeken naar migraties en hebben hun eigen taal-specifieke versies geïmplementeerd. Ik ken Ruckusing , een PHP migraties systeem dat is gemodelleerd naar Rails' migraties; Het zou kunnen zijn wat je zoekt.

antwoordde op 04/08/2008 om 23:45
bron van user

stemmen
48

We maken gebruik van iets wat lijkt op bcwoord aan onze database schema's gesynchroniseerd in 5 verschillende installaties (productie, staging en een paar ontwikkeling installaties) te houden, en een back-up in versie controle, en het werkt vrij goed. Ik zal een beetje uit te werken:


Om de database structuur te synchroniseren, hebben we een enkel script, update.php, en een aantal bestanden met het nummer 1.sql, 2.sql, 3.sql, etc. Het script maakt gebruik van een extra tafel om de huidige versie nummer van het op te slaan database. De N.sql bestanden worden met de hand vervaardigd, om te gaan vanaf versie (N-1) naar versie N van de database.

Ze kunnen worden gebruikt om tabellen gegevens uit een oude voegen, kolommen toevoegen, migreren naar een nieuwe kolom formaat dan vallen de kolom invoegen "master" data rijen zoals gebruiker typt, enz. Kortom, het kan van alles te doen, en met de juiste gegevens migratie scripts zul je nooit gegevens verloren gaan.

De update script werkt als volgt:

  • Verbinding maken met de database.
  • Maak een backup van de huidige database (omdat spul zal fout gaan) [mysqldump].
  • Maak boekhouding tafel (de zogenaamde _meta) indien het niet bestaat.
  • Lees huidige versie van _meta tafel. Veronderstel 0 indien niet gevonden.
  • Voor alle .sql bestanden met het nummer hoger is dan versie, uit te voeren ze in volgorde
  • Als een van de bestanden een fout geproduceerd: teruggaan naar de back-up
  • Anders is het actualiseren van de versie in de boekhouding tabel om de hoogste .sql bestand uitgevoerd.

Alles gaat in source control, en elke installatie heeft een script te updaten naar de nieuwste versie met een enkele uitvoering van het script (bellen update.php met de juiste database wachtwoord etc.). We SVN-update staging en productie-omgevingen via een script dat automatisch noemt de database update script, zodat een code update wordt geleverd met de nodige updates van de database.

We kunnen ook hetzelfde script gebruiken om de hele database van de grond af opnieuw; we gewoon verwijderen en opnieuw de database, voert u het script dat volledig de database opnieuw te bevolken. We kunnen ook het script gebruiken om een ​​lege database voor geautomatiseerd testen bevolken.


Het duurde slechts een paar uur voor het opzetten van dit systeem, het is conceptueel eenvoudig en iedereen krijgt de versie nummering regeling, en het is van onschatbare waarde geweest in het hebben van de mogelijkheid om verder te gaan en zich ontwikkelende de database-ontwerp, zonder om te communiceren of handmatig uit te voeren wijzigingen op alle databases.

Pas bij het plakken van vragen van phpMyAdmin hoor! Die gegenereerde query's zijn doorgaans voorzien van de naam van de database, die u zeker niet wilt omdat het je scripts zal breken! Iets als CREATE TABLE mydb. newtable(...) mislukt als de database op het systeem niet wordt genoemd mydb. We hebben een pre-commentaar SVN haak die zal verbieden Sql-bestanden met het mydbkoord, dat is een teken dat iemand copy / geplakt uit phpMyAdmin zonder de juiste controle.

antwoordde op 22/08/2008 om 15:44
bron van user

stemmen
11

Mijn team scripts alle wijzigingen in de database, en verbindt zich ertoe deze scripts om SVN, samen met elke versie van de applicatie. Dit zorgt voor incrementele veranderingen van de database, zonder gegevens te verliezen.

Om van de ene versie naar de volgende, je moet alleen de set van verandering scripts uit te voeren, en uw database up-to-date, en je heb nog steeds al uw gegevens. Het is misschien niet de gemakkelijkste methode, maar het is zeker effectief.

antwoordde op 05/08/2008 om 20:56
bron van user

stemmen
9

Als u nog steeds op zoek naar oplossingen: we stellen een tool genaamd neXtep ontwerper. Het is een database ontwikkelomgeving waarmee je je hele databank onder versie controle kan zetten. Je werkt aan een versie gecontroleerde repository waar elke verandering kunnen worden gevolgd.

Wanneer u een update vrij te geven, kunt u uw onderdelen te plegen en het product wordt automatisch genereren van de SQL-upgrade script van de vorige versie. Natuurlijk kunt u deze SQL vanaf elke 2 versies te genereren.

Dan heb je veel mogelijkheden: u kunt de scripts te nemen en zet ze in je SVN met je app code, zodat het zal worden ingezet door uw bestaande mechanisme. Een andere optie is om de levering mechanisme van neXtep gebruiken: scripts worden uitgevoerd in een zogenaamde "delivery-pakket" (SQL-scripts + XML descriptor), en een installateur kan dit pakket te begrijpen en in te zetten dat het een doel server en tegelijkertijd strcutural consistentie, afhankelijkheid controleren, registreren geïnstalleerde versie, etc.

Het product is GPL en is gebaseerd op Eclipse, zodat het draait op Linux, Mac en Windows. Het ondersteunt ook Oracle, Mysql en PostgreSQL momenteel (DB2 steun op de weg). Neem een kijkje op de wiki, waar u meer gedetailleerde informatie vindt u: http://www.nextep-softwares.com/wiki

antwoordde op 25/10/2010 om 06:46
bron van user

stemmen
9

Het probleem hier is echt het maken van het gemakkelijk voor ontwikkelaars om script van hun eigen lokale veranderingen in source control te delen met het team. Ik heb dit probleem voor vele jaren, en werd geïnspireerd door de functionaliteit van Visual Studio voor Database professionals. Als u een open-source tool met dezelfde kenmerken, probeer dit: http://dbsourcetools.codeplex.com/ Veel plezier, - Nathan.

antwoordde op 07/07/2009 om 14:26
bron van user

stemmen
6

Scott Ambler produceert een grote reeks artikelen (en co-auteur van een boek ) op de database refactoring, met het idee dat je in wezen TDD principes en praktijken moeten gelden voor het onderhoud van uw schema. U stelt een reeks van structuur en zaad data unit tests voor de database. Dan, voordat je iets verandert, kunt wijzigen / schrijven tests om die verandering te weerspiegelen.

We doen dit nu al een tijdje en het lijkt te werken. We schreven code tot basisvoorzieningen naam en datatype kolom controle in een unit testing suite genereren. We kunnen die tests op elk gewenst moment opnieuw uitvoeren om te controleren of de database in het SVN checkout overeenkomt met de live-db de aanvraag daadwerkelijk wordt uitgevoerd.

Het blijkt dat, ontwikkelaars soms ook tweak hun sandbox-database en verwaarlozing om het schema bestand in SVN te werken. De code is dan afhankelijk van een db verandering die niet is ingecheckt. Dat soort bug kan maddeningly moeilijk zijn vast te pinnen, maar de test suite zal oppakken meteen. Dit is vooral leuk als je het in een grotere Continuous Integratieplan gebouwd.

antwoordde op 29/08/2008 om 05:51
bron van user

stemmen
6

Dump je schema in een bestand en voeg deze toe aan de bron controle. Dan zal een eenvoudige diff je laten zien wat er veranderd is.

antwoordde op 06/08/2008 om 17:59
bron van user

stemmen
5

K. Scott Allen heeft een fatsoenlijke artikel of twee op schema versiebeheer, waarin de tussentijdse update scripts / migraties begrip waarnaar wordt verwezen in andere antwoorden hier gebruikt; zie http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

antwoordde op 29/08/2008 om 06:11
bron van user

stemmen
5

Als u gebruik maakt C #, neem een ​​kijkje op Subsonic, een zeer nuttig ORM tool, maar genereert ook sql script om uw systeem en \ of gegevens opnieuw. Deze scripts kan dan in de bron controle worden gebracht.

http://subsonicproject.com/

antwoordde op 04/08/2008 om 23:47
bron van user

stemmen
5

Het is een beetje low-tech, en er dan uit kan er een betere oplossing zijn, maar je kon gewoon opslaan van uw schema in een SQL-script dat kan worden uitgevoerd om de database te maken. Ik denk dat je kunt een opdracht uit te voeren om dit script te genereren, maar ik weet niet helaas weten de opdracht.

Vervolgens plegen door het script in source control, samen met de code die werkt op het. Wanneer je nodig hebt om het schema te veranderen, samen met de code, kan het script worden gecontroleerd, samen met de code die de gewijzigde schema vereist. Dan zal diffs aan het script diffs op schema wijzigingen aan te geven.

Met dit script, kan je het integreren met DbUnit of een soort van de te bouwen script, zo lijkt het zou kunnen passen in uw reeds geautomatiseerde processen.

antwoordde op 04/08/2008 om 23:28
bron van user

stemmen
4

Ik heb de volgende database-project structuur in Visual Studio gebruikt voor verschillende projecten en het is vrij goed gewerkt:

Database

Scripts wijzigen

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Maak Scripts

sprocs

functies

Keer bekeken

Onze build systeem werkt dan is de database van de ene versie naar de volgende door het uitvoeren van de scripts in de volgende volgorde:

1.PreDeploy.sql

2.SchemaChanges.sql

Inhoud van Create Scripts folder

2.DataChanges.sql

3.Permissions.sql

Elke ontwikkelaar controles in hun wijzigingen voor een bepaalde bug / feature door het toevoegen van de code op het einde van elk bestand. Zodra een belangrijke versie is compleet en vertakt in source control, wordt de inhoud van de .sql bestanden in de map Change Scripts verwijderd.

antwoordde op 08/08/2008 om 19:31
bron van user

stemmen
4

We maken gebruik van een zeer eenvoudige maar toch effectieve oplossing.

Voor nieuwe installaties, hebben we een metadata.sql bestand in de repository waarin alle DB-schema in het bouwproces we dit bestand gebruiken om de database te genereren houdt, dan.

Voor updates, we de updates toe te voegen in de software hardcoded. We houden het hardcoded omdat we niet willen problemen op te lossen voordat het echt een probleem is, en dit soort dingen niet blijken te zijn een probleem tot nu toe.

Dus in onze software hebben we zoiets als dit:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Deze code zal controleren of de database is in versie 1 (die is opgeslagen in een tabel automatisch aangemaakt), als het is verouderd, dan wordt de opdracht uitgevoerd.

Om de metadata.sql in de repository te werken, lopen we deze upgrades lokaal en pak vervolgens de volledige database met metadata.

Het enige dat elke zo vaak gebeurt, is om te vergeten het plegen van de metadata.sql, maar dit is geen groot probleem, omdat het makkelijk om te testen op het bouwproces en ook het enige wat er kan gebeuren is om een ​​nieuwe installatie met een verouderde database en verbeterde het op het eerste gebruik.

Ook wij niet downgrades ondersteunen, maar het is door het ontwerp, als er iets breekt aan een update, herstelde we de vorige versie en bevestig de update alvorens opnieuw te proberen.

antwoordde op 08/08/2008 om 19:21
bron van user

stemmen
3

Ik maak mappen vernoemd naar de build-versies en Put upgraden en downgraden scripts in daar. Bijvoorbeeld, zou u de volgende mappen: 1.0.0, 1.0.1 en 1.0.2. Elk bevat het script dat kunt u upgraden of downgraden uw database tussen de versies.

Mocht een klant of een klant belt u met een probleem met versie 1.0.1 en u gebruikt 1.0.2, waardoor de database terug naar zijn versie zal geen probleem zijn.

In uw database, maakt u een tabel met de naam "schema", waar je in de huidige versie van de database. Dan het schrijven van een programma dat kan upgraden of downgraden uw database voor u is eenvoudig.

Net als Joey zei, als je in een Rails wereld, gebruiken Migrations. :)

antwoordde op 05/08/2008 om 05:36
bron van user

stemmen
2

Probeer db implementeren - vooral een Java-tool, maar werkt met php ook.

antwoordde op 19/01/2012 om 02:52
bron van user

stemmen
2

Ik hou van de manier waarop Yii behandelt de database migraties. Een migratie is in feite een PHP-script implementeren CDbMigration. CDbMigrationdefinieert een upmethode die de migratie logica bevat. Het is ook mogelijk om een uitvoering downwerkwijze voor omkering van de migratie ondersteunen. Als alternatief, safeUpof safeDownkan worden gebruikt om te controleren of de migratie gebeurt in het kader van een transactie.

Yii's command-line tool yiicbevat ondersteuning voor het maken en uitvoeren van migraties. Migraties worden toegepast of omgekeerd, één voor één of in een batch. Het creëren van een migratie resulteert in code voor een PHP klasse uitvoering CDbMigration, een unieke naam op basis van een tijdstempel en een migratie is opgegeven door de gebruiker. Alle migraties die eerder zijn toegepast op de database worden opgeslagen in een migratietabel.

Voor meer informatie zie de Database Migration artikel uit de handleiding.

antwoordde op 25/06/2011 om 14:18
bron van user

stemmen
2

IMHO migraties hebben een groot probleem:

Het upgraden van de ene versie naar de andere werkt prima, maar het doen van een verse installatie van een bepaalde versie kan altijd te nemen als je honderden tafels en een lange geschiedenis van de veranderingen (zoals wij doen) te hebben.

Het uitvoeren van de hele geschiedenis van delta's sinds de basislijn tot aan de huidige versie (voor honderden klanten databases) kan een zeer lange tijd in beslag nemen.

antwoordde op 12/03/2011 om 15:15
bron van user

stemmen
2

Pad voor MySQL heeft een functie genaamd schema te vergelijken, waarmee u 2 databases te synchroniseren. Het is het beste hulpmiddel dat ik tot nu toe gebruikt.

antwoordde op 05/02/2011 om 12:08
bron van user

stemmen
2

Ik raad je aan om Ant (cross-platform) voor de "scripting" kant (omdat het praktisch elke db kan praten die er via JDBC) en Subversion voor de bron repository. Ant zal je alow aan "back-up" uw db tot lokale bestanden, voordat u wijzigingen aanbrengt. 1. backup bestaande db schema naar een bestand via Ant 2. versie controle naar Subversion repository via Ant 3. stuur nieuwe SQL-statements om db via Ant

antwoordde op 17/09/2008 om 17:54
bron van user

stemmen
2

Voor mijn huidige PHP project gebruiken we het idee van de rails migraties en we hebben een migraties directory waarin we houden bestanden titel "migration_XX.sql" waarbij XX is het nummer van de migratie. Momenteel worden deze bestanden worden gemaakt met de hand en updates zijn gemaakt, maar hun creatie kan eenvoudig worden aangepast.

Dan hebben we een script genaamd "Migration_watcher" die, zoals we in de pre-alpha, die momenteel draait op elke pagina te laden en controleert of er een nieuw migration_XX.sql bestand waarbij XX is groter dan de huidige migratie-versie. Als dat zo is het loopt allemaal migration_XX.sql bestanden tot het grootste aantal tegen de database en voila! schema wijzigingen worden geautomatiseerd.

Als u de mogelijkheid om het systeem zou heel wat tweaken vereist terugkeren nodig, maar het is eenvoudig en is zeer goed werken voor ons vrij klein team tot nu toe.

antwoordde op 23/08/2008 om 13:58
bron van user

stemmen
0

Er is een command-line mysql-diff tool die database schema's, waarbij schema een live-database of SQL-script op de harde schijf kan worden vergeleken. Het is goed voor de meeste schema migratie taken.

antwoordde op 04/11/2009 om 20:43
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more