Mekanismer for sporing DB skjemaendringer

stemmer
129

Hva er de beste metodene for sporing og / eller automat DB skjemaendringer? Vårt team bruker Subversion for versjonskontroll, og vi har vært i stand til å automatisere noen av våre oppgaver på denne måten (presser bygger seg opp til en iscenesettelse server, distribusjon testet kode til en produksjonsserver), men vi er fortsatt gjør database oppdateringer manuelt. Jeg ønsker å finne eller lage en løsning som gjør det mulig for oss å arbeide effektivt på tvers av servere med ulike miljøer mens du fortsetter å bruke Subversion som en backend gjennom som kode og DB oppdateringer er skjøvet rundt til forskjellige servere.

Mange populære programvarepakker inkluderer automatisk oppdatering skript som oppdager DB versjon og bruke de nødvendige endringene. Er dette den beste måten å gjøre dette selv på en større skala (på tvers av flere prosjekter og noen ganger flere miljøer og språk)? I så fall er det noen eksisterende kode der ute som forenkler prosessen eller er det best bare å rulle vår egen løsning? Har noen gjennomført noe lignende før, og integrert den i Subversion post-commit kroker, eller er dette en dårlig idé?

Mens en løsning som støtter flere plattformer vil være å foretrekke, vi definitivt trenger å støtte Linux / Apache / MySQL / PHP stack som de fleste av vårt arbeid er på denne plattformen.

Publisert på 04/08/2008 klokken 21:31
kilden bruker
På andre språk...                            


20 svar

stemmer
55

I Rails verden, det er begrepet vandringer, skript der endringer til databasen er laget i Ruby snarere enn en database-spesifikk smak av SQL. Din Ruby migrasjon kode ender opp med å bli konvertert til DDL spesifikke for din nåværende database; dette gjør bytte databaseplattformer veldig enkelt.

For hver endring du gjør i databasen, skriver du en ny migrasjon. Migreringer har vanligvis to metoder: en "opp" metode hvor endringer brukes og en "ned" metode hvor endringene ugjort. En enkel kommando bringer databasen oppdatert, og kan også brukes til å bringe databasen til en bestemt versjon av skjemaet. I Rails, blir vandringer holdt i sin egen katalog i prosjektkatalogen og få sjekket inn versjonskontroll akkurat som alle andre prosjektkode.

Dette Oracle guide til Rails vandringer dekker vandringer ganske godt.

Utviklere som bruker andre språk har sett på vandringer og har gjennomført sine egne språkspesifikke versjoner. Jeg vet om Ruckusing , en PHP vandringer system som er modellert etter Rails' vandringer; det kan være det du leter etter.

Svarte 04/08/2008 kl. 22:45
kilden bruker

stemmer
48

Vi bruker noe som ligner på bcwoord å holde våre database schemata synkronisert over 5 forskjellige installasjoner (produksjon, regi og noen utviklings installasjoner), og støttet opp i versjonskontroll, og det fungerer ganske bra. Jeg skal utdype litt:


Å synkronisere databasen strukturen, har vi et enkelt script, update.php, og en rekke filer nummererte 1.sql, 2.sql, 3.sql, etc. skriptet bruker en ekstra tabell for å lagre gjeldende versjonsnummer database. De N.sql filene er laget for hånd, for å gå fra versjon (N-1) til versjon N av databasen.

De kan brukes til å legge til tabeller, legge til kolonner, overføre data fra en gammel til en ny kolonne format deretter slippe kolonnen, må du sette "master" datarader som brukeren skriver etc. I utgangspunktet kan det gjøre noe, og med riktig data migrasjon skript du vil aldri miste data.

Oppdateringen skriptet fungerer slik:

  • Koble til databasen.
  • Lag en sikkerhetskopi av gjeldende database (fordi ting vil gå galt) [mysqldump].
  • Lag bokføring tabellen (kalt _meta) hvis den ikke eksisterer.
  • Les gjeldende versjon fra _meta tabellen. Anta 0 hvis ikke funnet.
  • For alle .SQL filene nummerert høyere enn versjon, kjøre dem i rekkefølge
  • Hvis en av filene produsert en feil: rulle tilbake til backup
  • Ellers oppdatere versjonen i bokføringen tabellen til høyeste sql filen henrettet.

Alt går inn kildekontroll, og hver installasjon har et skript for å oppdatere til den nyeste versjonen med en enkelt skriptkjøring (ringer update.php med riktig databasepassord osv). Vi svn update regi og produksjonsmiljøer via et script som automatisk kaller database oppdatering script, så en kode oppdatering kommer med de nødvendige database oppdateringer.

Vi kan også bruke den samme skriptet til å gjenskape hele databasen fra bunnen av; vi bare slette og gjenopprette databasen, og deretter kjøre script som vil fullstendig repopulate databasen. Vi kan også bruke skriptet til å fylle en tom database for automatisert testing.


Det tok bare et par timer å sette opp dette systemet, det er konseptuelt enkelt og alle får den versjonen nummerering ordningen, og det har vært uvurderlig i å ha muligheten til å gå videre og utvikler databasen design, uten å kommunisere eller manuelt utføre modifikasjoner på alle databaser.

Vær forsiktig når du limer inn forespørsler fra phpMyAdmin skjønt! De genererte spørringer inkluderer vanligvis databasenavnet, som du definitivt ikke ønsker siden det vil bryte skript! Noe som CREATE TABLE mydb. newtable(...) vil mislykkes hvis databasen på systemet ikke kalles mydb. Vi skapte en pre-kommentar SVN krok som vil forby sql filer som inneholder mydbstrengen, som er et sikkert tegn på at noen kopi / limt inn fra phpMyAdmin uten skikkelig kontroll.

Svarte 22/08/2008 kl. 14:44
kilden bruker

stemmer
11

Mitt team scripts ut alle databaseendringer, og forplikter de skriptene til SVN, sammen med hver utgivelse av søknaden. Dette gir trinnvise endringer i databasen, uten å miste data.

Å gå fra en utgivelse til den neste, du trenger bare å kjøre sett av endrings skript, og databasen er up-to-date, og du har fortsatt alle dine data. Det kan ikke være den enkleste metoden, men det er definitivt effektive.

Svarte 05/08/2008 kl. 19:56
kilden bruker

stemmer
9

Hvis du fortsatt leter etter løsninger: Vi foreslår et verktøy kalt neXtep designer. Det er en database utviklingsmiljø som du kan sette hele databasen under versjonskontroll. Du jobber med en versjon kontrollert depot der hver endring kan spores.

Når du trenger å slippe en oppdatering, kan du begå komponentene og produktet vil automatisk generere SQL oppgraderingsskriptet fra forrige versjon. Selvfølgelig kan du generere denne SQL fra alle 2 versjoner.

Da har du mange muligheter: du kan ta disse skriptene og sette dem i SVN med din app-koden slik at det vil bli utplassert ved eksisterende mekanisme. Et annet alternativ er å bruke levering mekanisme neXtep: skript eksporteres i noe som kalles en "levering pakke" (SQL-skript + XML descriptor), og et installasjonsprogram kan forstå denne pakken og distribuere den til en målserveren samtidig strcutural konsistens, avhengighet sjekk, registrere installert versjon, etc.

Produktet er GPL og er basert på Eclipse så den kjører på Linux, Mac og Windows. Det støtter også Oracle, MySQL og PostgreSQL i øyeblikket (DB2-støtte er på vei). Ta en titt på wikien hvor du finner mer detaljert informasjon: http://www.nextep-softwares.com/wiki

Svarte 25/10/2010 kl. 05:46
kilden bruker

stemmer
9

Spørsmålet her er virkelig noe som gjør det enkelt for utviklere å skript egne lokale endringer i kildekontroll for å dele med teamet. Jeg har møtt dette problemet i mange år, og ble inspirert av funksjonaliteten til Visual Studio for database fagfolk. Hvis du ønsker en åpen kildekode-verktøy med de samme funksjonene, prøv dette: http://dbsourcetools.codeplex.com/ Ha det gøy, - Nathan.

Svarte 07/07/2009 kl. 13:26
kilden bruker

stemmer
6

Scott Ambler produserer en stor serie artikler (og medforfatter av en bok ) på database refactoring, med ideen om at du bør egentlig bruke TDD prinsipper og praksis for å opprettholde din skjema. Man sette opp en serie av struktur og frø data enhetstester for databasen. Da, før du endrer noe, du endre / skrive tester for å reflektere at endringen.

Vi har gjort dette for en stund nå, og det ser ut til å fungere. Vi skrev kode for å generere grunnleggende kolonnenavn og datatype sjekker i en enhetstesting suite. Vi kan kjøre de testene som helst for å kontrollere at databasen i SVN kassa kamper live db programmet er faktisk kjører.

Som det viser seg, utviklere også noen ganger finpusse sin sandkasse database og unnlater å oppdatere skjemaet filen i SVN. Koden avhenger da på en db endring som ikke har blitt sjekket inn. Den slags insekt kan være maddeningly vanskelig å peke ut, men testsuiten vil plukke den opp med en gang. Dette er spesielt fint om du har det bygget inn en større kontinuerlig integrasjon plan.

Svarte 29/08/2008 kl. 04:51
kilden bruker

stemmer
6

Dumpe skjema til en fil og legge den til kildekontroll. Deretter en enkel diff vil vise deg hva som er endret.

Svarte 06/08/2008 kl. 16:59
kilden bruker

stemmer
5

K. Scott Allen har en anstendig artikkel eller to på skjema versjonskontroll, som bruker inkrementell oppdatering scripts / vandringer konsept referert i andre svar her; se http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Svarte 29/08/2008 kl. 05:11
kilden bruker

stemmer
5

Hvis du bruker C #, ta en titt på Subsonic, et svært nyttig ORM verktøy, men også genererer sql skript for å gjen ordningen og \ eller data. Disse skriptene kan da bli satt inn i kildekontroll.

http://subsonicproject.com/

Svarte 04/08/2008 kl. 22:47
kilden bruker

stemmer
5

Det er ganske lav tech, og det kan være en bedre løsning der ute, men du kan bare lagre skjemaet i en SQL-script som kan kjøres for å opprette databasen. Jeg tror du kan utføre en kommando for å generere dette skriptet, men jeg vet ikke kommandoen dessverre.

Deretter begår skriptet inn kildekontroll sammen med kode som virker på den. Når du trenger å endre skjemaet sammen med koden, kan skriptet skal sjekkes inn sammen med koden som krever endrede skjemaet. Deretter vil differ på manuset tyder differ på skjemaendringer.

Med dette skriptet, kan du integrere den med DBUnit eller annen form for bygge script, så det synes det kan passe inn med allerede automatiserte prosesser.

Svarte 04/08/2008 kl. 22:28
kilden bruker

stemmer
4

Jeg har brukt følgende databaseprosjektstrukturen i Visual Studio for flere prosjekter, og det har fungert ganske bra:

database

Endre Scripts

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Lag Scripts

Sprocs

funksjoner

Visninger

Vår build system oppdaterer deretter databasen fra en versjon til den neste ved å kjøre skript i følgende rekkefølge:

1.PreDeploy.sql

2.SchemaChanges.sql

Innholdet Opprett Scripts mappen

2.DataChanges.sql

3.Permissions.sql

Hver utvikler sjekker i sine endringer for en bestemt feil / funksjon ved å legge sin kode på slutten av hver fil. Når en hovedversjon er komplett og forgrenet i kildekontroll, blir innholdet i .SQL filene i Endre Scripts mappen slettet.

Svarte 08/08/2008 kl. 18:31
kilden bruker

stemmer
4

Vi bruker en veldig enkel, men likevel effektiv løsning.

For nye installasjoner, har vi en metadata.sql fil i depotet som holder hele DB skjema, deretter i byggeprosessen vi bruker denne filen til å generere databasen.

For oppdateringer, legger vi oppdateringene i programvaren hardkodet. Vi holder det hardkodet fordi vi ikke liker å løse problemer før det virkelig er et problem, og denne type ting ikke vise seg å være et problem så langt.

Så i vår programvare vi har noe sånt som dette:

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

Denne koden vil sjekke om databasen er i versjon 1 (som er lagret i en tabell som er opprettet automatisk), hvis den er utdatert, så kommandoen utføres.

For å oppdatere metadata.sql i depotet, kjører vi denne oppgraderer lokalt og deretter trekke ut hele databasen metadata.

Det eneste som skjer hver så ofte, er å glemme forplikter den metadata.sql, men dette er ikke et stort problem, fordi det er lett å teste om byggeprosessen og også den eneste som kan skje er å gjøre en ny installasjon med en utdatert database og oppgradert det ved første gangs bruk.

Også vi ikke støtter nedgraderinger, men det er ved design, hvis noe bryter på en oppdatering, restaurert vi den forrige versjonen og fikse oppdateringen før du prøver igjen.

Svarte 08/08/2008 kl. 18:21
kilden bruker

stemmer
3

Jeg oppretter mapper oppkalt etter bygge versjonene og sette oppgradering og nedgradering skript der. For eksempel kan du ha følgende mapper: 1.0.0, 1.0.1 og 1.0.2. Hver og en inneholder skript som gjør at du kan oppgradere eller nedgradere databasen mellom versjonene.

Dersom en klient eller kunde ringe deg med et problem med versjon 1.0.1, og du bruker 1.0.2, og bringer databasen tilbake til sin versjon vil ikke være et problem.

I databasen, opprette en tabell som heter "skjema" der du putter i den gjeldende versjonen av databasen. Deretter skrive et program som kan oppgradere eller nedgradere databasen for deg er enkel.

Akkurat som Joey sagt, hvis du er i et Rails verden, bruker Migrations. :)

Svarte 05/08/2008 kl. 04:36
kilden bruker

stemmer
2

Prøv db-distribuere - hovedsakelig en Java verktøy, men jobber med php også.

Svarte 19/01/2012 kl. 01:52
kilden bruker

stemmer
2

Jeg liker måten hvordan Yii håndterer database vandringer. En migrasjon er i utgangspunktet et PHP-script implementering CDbMigration. CDbMigrationdefinerer en upmetode som inneholder migreringen logikk. Det er også mulig å implementere en downmetode for å støtte reversering av migreringen. Alternativt, safeUpeller safeDownkan brukes for å sikre at overføringen er gjort i forbindelse med en transaksjon.

Yii er kommandolinjeverktøyet yiicinneholder støtte for å lage og gjennomføre vandringer. Overføringer kan påføres eller reverseres, enten enkeltvis eller i en batch. Opprette en migrering resulterer i koden for en PHP klasse implementering CDbMigration, unike navn basert på et tidsstempel og en migrering navn spesifisert av brukeren. Alle overføringer som tidligere er blitt brukt til databasen, er lagret i en migrasjons tabell.

For mer informasjon se Database Migration artikkel fra manualen.

Svarte 25/06/2011 kl. 13:18
kilden bruker

stemmer
2

IMHO vandringer har et stort problem:

Oppgradering fra en versjon til en annen fungerer fint, men gjør en fersk installasjon av en gitt versjon kan ta for alltid hvis du har hundrevis av tabeller og en lang historie med endringer (som vi gjør).

Kjører hele historien deltaer siden grunnlinjen opp til den gjeldende versjonen (for hundrevis av kunder databaser) kan ta svært lang tid.

Svarte 12/03/2011 kl. 14:15
kilden bruker

stemmer
2

Toad for MySQL har en funksjon som kalles skjema sammenligne som lar deg synkronisere 2 databaser. Det er det beste verktøyet jeg har brukt så langt.

Svarte 05/02/2011 kl. 11:08
kilden bruker

stemmer
2

Jeg vil anbefale å bruke Ant (cross platform) for "scripting" side (siden det kan praktisk talt snakke med noen db der ute via JDBC) og Subversion for kilden depotet. Ant vil alow deg å "back up" din db til lokale filer, før du gjør endringer. 1. backup eksisterende db skjema til fil via Ant 2. versjonskontroll til Subversion repository via Ant 3. sende nye SQL-setninger til DB via Ant

Svarte 17/09/2008 kl. 16:54
kilden bruker

stemmer
2

For min nåværende PHP-prosjektet bruker vi ideen om rails vandringer og vi har en vandringer katalog der vi holde filene tittelen "migration_XX.sql" der XX er nummeret på migrasjon. Foreløpig disse filene er laget for hånd som oppdateringer blir gjort, men deres skapelse kan enkelt endres.

Da har vi et manus som heter "Migration_watcher" som, som vi er i pre-alpha, som for tiden går på hver side belastning og sjekker om det er en ny migration_XX.sql fil der XX er større enn dagens migrasjon versjon. Hvis så det går alle migration_XX.sql filer opp til det største antall mot databasen og voila! skjema endringer er automatisert.

Hvis du krever evne til å tilbakestille systemet vil kreve mye tilpasning, men det er enkelt og har jobbet veldig bra for vår ganske lite team så langt.

Svarte 23/08/2008 kl. 12:58
kilden bruker

stemmer
0

Det er et kommandolinje mysql-diff verktøy som sammendatabaseskjemaer, hvor skjema kan være en levende database eller SQL-skript på disk. Det er bra for de fleste skjema migreringsoppgaver.

Svarte 04/11/2009 kl. 19:43
kilden bruker

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