Er det et versjonskontrollsystem for database struktur endringer?

stemmer
110

Jeg ofte kjøre inn følgende problem.

Jeg jobber på noen endringer i et prosjekt som krever nye tabeller eller kolonner i databasen. Jeg gjør databasen endringer og fortsette mitt arbeid. Vanligvis jeg huske å skrive ned de endringer slik at de kan bli replikert på live-system. Men jeg har ikke alltid huske hva jeg har endret seg og jeg ikke alltid husker å skrive det ned.

Så jeg gjør en push til live systemet og få en stor, åpenbar feil at det ikke er NewColumnX, ugh.

Uavhengig av det faktum at dette ikke kan være den beste praksis for denne situasjonen, er det et versjonskontrollsystem for databaser? Jeg bryr meg ikke om den spesifikke databaseteknologi. Jeg vil bare vite om det finnes. Hvis det skjer for å arbeide med MS SQL Server, så flott.

Publisert på 02/08/2008 klokken 01:52
kilden bruker
På andre språk...                            


22 svar

stemmer
59

I Ruby on Rails, det er et konsept av en migrering - en rask skript for å endre databasen.

Du genererer et migrerings fil, som har regler for å øke db utførelse (slik som tilsetning av en kolonne) og regler for å nedgradere utførelse (for eksempel fjerning av en kolonne). Hver migrasjon er nummerert, og et bord holder styr på din nåværende db versjon.

Å migrere opp , kjører du en kommando som heter "db: migrere" som ser på din versjon og gjelder de nødvendige skript. Du kan migrere ned på en lignende måte.

Migrasjon skript selv er holdt i et versjonskontrollsystem - når du endrer databasen du sjekker inn et nytt manus, og noen utvikler kan bruke den til å bringe deres lokale db til den nyeste versjonen.

Svarte 02/08/2008 kl. 06:23
kilden bruker

stemmer
29

Jeg er litt old-school, i at jeg bruker kildefiler for å lage databasen. Det er faktisk 2 filer - prosjekt database.sql og prosjekt updates.sql - den første for skjemaet og vedvarende data, og den andre for modifikasjoner. Selvfølgelig, begge er under kildekontroll.

Når database endringer, jeg først oppdatere hovedskjemaet i prosjekt database.sql, deretter kopiere relevant info til prosjekt updates.sql, for eksempel ALTER TABLE uttalelser. Jeg kan da søke oppdateringene til utvikling database, test, iterere inntil gjort det bra. Deretter sjekke inn filer, test igjen, og gjelder for produksjon.

Også, jeg har vanligvis en tabell i db - Config - for eksempel:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Deretter legger jeg følgende til oppdateringsdelen:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Det db_versionbare blir endret når databasen er gjenskapt, og den db_revisiongir meg en indikasjon på hvor langt db er av grunnlinjen.

Jeg kunne holde oppdateringene i sine egne separate filer, men jeg valgte å mose dem alle sammen og bruke klipp og lim for å trekke relevante deler. Litt mer rengjøring er i orden, dvs. fjerne ':' fra $ Revision 1.1 $ å fryse dem.

Svarte 26/09/2008 kl. 20:29
kilden bruker

stemmer
11

Redgate har et produkt som kalles SQL kildekontroll . Det kan integreres med TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce, og Git.

Svarte 08/07/2011 kl. 14:51
kilden bruker

stemmer
11

MyBatis (tidligere iBatis) har et skjema migrering , verktøy for bruk på kommandolinjen. Det er skrevet i java men kan brukes med ethvert prosjekt.

For å oppnå en god database endringsledelse praksis, må vi identifisere noen viktige mål. Dermed MyBatis Schema Migration System (eller MyBatis Migrations for kort) søker å:

  • Arbeid med noen database, ny eller eksisterende
  • Benytter kildestyringssystem (f.eks Subversion)
  • Aktiver samtidige utviklere eller team å jobbe selvstendig
  • Tillat konflikter svært synlig og lett håndterlig
  • Tillat for frem og tilbakemigrering (utvikle seg, tilfaller henholdsvis)
  • Gjør gjeldende status for databasen lett tilgjengelig og forståelig
  • Aktiver vandringer tross tilgangsrettigheter eller byråkrati
  • Arbeide med noen metodikk
  • Oppfordrer god, konsistent praksis
Svarte 10/07/2010 kl. 21:56
kilden bruker

stemmer
10

Jeg lurer på at ingen nevnte open source verktøy liquibase som er Java-basert og skal fungere for nesten alle database som støtter JDBC. Sammenlignet med rails bruker den xml stedet ruby å utføre skjemaendringer. Selv om jeg misliker xml for domenespesifikt språk veldig kul nytte av XML er at liquibase vet hvordan å rulle tilbake visse operasjoner som

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Så du trenger ikke å håndtere dette på egen hånd

Pure SQL-setninger eller dataimport er også støttet.

Svarte 10/07/2010 kl. 21:26
kilden bruker

stemmer
10

Jeg anbefaler SQL delta . Jeg bare bruke den til å generere diff skript når jeg er ferdig koding min funksjon og sjekk disse skriptene inn i min kilde styringsverktøy (Mercurial :))

De har begge en SQL server og Oracle versjon.

Svarte 28/05/2009 kl. 02:12
kilden bruker

stemmer
10

De fleste databasemotorer bør støtte dumping databasen til en fil. Jeg vet MySQL gjør, uansett. Dette vil bare være en tekstfil, så du kan sende det til Subversion, eller hva du bruker. Det ville være enkelt å kjøre en diff på filene også.

Svarte 02/08/2008 kl. 01:56
kilden bruker

stemmer
8

Hvis du bruker SQL Server det ville være vanskelig å slå data Dude (aka Database Edition av Visual Studio). Når du får taket på det, gjør et skjema sammenligne mellom kildestyrt versjon av databasen og den versjonen i produksjonen er en lek. Og med et klikk kan du generere din diff DDL.

Det er en instruksjons video på MSDN som er veldig nyttig.

Jeg vet om DBMS_METADATA og Toad, men hvis noen kunne komme opp med en data Dude for Oracle så livet ville være veldig søt.

Svarte 10/09/2008 kl. 19:49
kilden bruker

stemmer
8

For Oracle, jeg bruker Toad , som kan dumpe et skjema til en rekke diskrete filer (for eksempel en fil per tabell). Jeg har noen skript som administrerer denne samlingen i Perforce, men jeg tror det skal være lett gjennomførbart i omtrent alle revisjonskontroll system.

Svarte 02/08/2008 kl. 06:05
kilden bruker

stemmer
7

Ta en titt på oracle pakken DBMS_METADATA.

Spesielt er følgende fremgangsmåter spesielt nyttige:

  • DBMS_METADATA.GET_DDL
  • DBMS_METADATA.SET_TRANSFORM_PARAM
  • DBMS_METADATA.GET_GRANTED_DDL

Når du er kjent med hvordan de fungerer (ganske selvforklarende) du kan skrive et enkelt skript å dumpe resultatene av disse metodene til tekstfiler som kan bli satt under kildekontroll. Lykke til!

Ikke sikker på om det er noe denne enkle for MSSQL.

Svarte 01/09/2008 kl. 20:57
kilden bruker

stemmer
7

Ha innledende lage tabell uttalelser i versjon kontrolleren, og deretter legge ALTER TABLE uttalelser, men aldri redigere filer, bare mer endre filer ideelt oppkalt sekvensielt, eller som en "endring set", slik at du kan finne alle endringer for en bestemt distribusjon.

Den tøffeste delen som jeg kan se, er sporing avhengigheter, for eksempel for en bestemt distribusjon tabell B må kanskje bli oppdatert før tabellen A.

Svarte 31/08/2008 kl. 11:25
kilden bruker

stemmer
6

PLSQL Developer, et verktøy fra alle arround Automations, har en plugin for arkiver som fungerer OK (men ikke stor) med Visual Source Safe.

Fra nettet:

Versjonskontroll Plug-In gir en tett integrasjon mellom PL / SQL Developer IDE >> og noen versjonskontrollsystem som støtter Microsoft SCC Interface Specification. >> Dette inkluderer mest populære versjonskontrollsystemer som Microsoft Visual Source, >> Merant PVCS og MKS Kilde integritet.

http://www.allroundautomations.com/plsvcs.html

Svarte 17/09/2008 kl. 15:50
kilden bruker

stemmer
6

Jeg har gjort dette av og på i år - administrere (eller prøver å administrere) skjema versjoner. De beste tilnærminger avhengig av de verktøyene du har. Hvis du kan få Quest Software funksjonen "Schema Manager" vil du være i god form. Oracle har sin egen, dårligere verktøy som også kalles "Schema Manager" (forvirrende mye?) Som jeg ikke anbefaler.

Uten et automatisert verktøy (se andre kommentarer her om data Dude), så du skal bruke skript og DDL-filer direkte. Plukk en tilnærming, dokumentere det, og følge den nøye. Jeg liker å ha muligheten til å gjenskape databasen til enhver tid, så jeg foretrekker å ha en full DDL eksport av hele databasen (hvis jeg er DBA), eller av utbygger skjema (hvis jeg er i produktet -utvikling modus).

Svarte 15/09/2008 kl. 15:01
kilden bruker

stemmer
6

Jeg skriver mine db utgivelsen skript parallelt med koding, og holde utløser skript i et prosjekt bestemt del i SS. Hvis jeg gjør en endring i koden som krever en db endring, så jeg oppdatere utgivelsen skript samtidig. Før utgivelse, jeg kjører utgivelsen skript på en ren dev db (kopiert struktur klok fra produksjon) og gjøre mitt endelige testing på den.

Svarte 30/08/2008 kl. 18:58
kilden bruker

stemmer
6

Det er en PHP5 "database migrasjon rammeverk" kalt Ruckusing. Jeg har ikke brukt det, men eksemplene viser ideen, hvis du bruker språket til å opprette databasen etter behov, trenger du bare å spore kildefilene.

Svarte 02/08/2008 kl. 07:48
kilden bruker

stemmer
5

ER Studio kan du reversere databaseskjema i verktøyet, og du kan deretter sammenligne det å leve databaser.

Eksempel: Motsatt din utvikling skjema i ER Studio - sammenligne det til produksjon, og det vil liste opp alle forskjellene. Det kan script endringene eller bare presse dem gjennom automatisk.

Når du har et skjema i ER Studio, kan du enten lagre etableringen skript eller lagre det som en proprietær binær og lagre den i versjonskontroll. Hvis du noen gang vil gå tilbake til en tidligere versjon av ordningen, bare sjekk den ut og skyv den til db-plattformen.

Svarte 17/09/2008 kl. 18:04
kilden bruker

stemmer
3

Du kan bruke Microsoft SQL Server Dataverktøy i Visual Studio til å generere skript for databaseobjekter som en del av en SQL Server Project. Du kan deretter legge til skript for å kildekontroll ved bruk av kildekontroll integrering som er innebygd i Visual Studio. Også SQL Server Prosjekter lar deg kontrollere databaseobjekter ved hjelp av en kompilator og generere distribusjon skript for å oppdatere en eksisterende database eller opprette en ny.

Svarte 22/12/2014 kl. 11:58
kilden bruker

stemmer
2

Schema Sammenlign for Oracle er et verktøy spesielt designet for å migrere endringer fra vår Oracle database til en annen. Vennligst gå til nettadressen nedenfor for nedlastingslink, hvor du vil være i stand til å bruke programvaren for en fullt fungerende prøve.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Svarte 10/01/2010 kl. 02:59
kilden bruker

stemmer
2

Vi har brukt MS Team System Database Edition med ganske god suksess. Det kan integreres med TFS versjonskontroll og Visual Studio mer eller mindre sømløst og lar oss klarer lagrede procs, synspunkter osv, lett. Konfliktløsning kan være smertefullt, men versjon historie er ferdig når den er ferdig. Deretter flyttinger til QA og produksjon er svært enkel.

Det er rimelig å si at det er en versjon 1.0 produkt, skjønt, og er ikke uten noen problemer.

Svarte 26/09/2008 kl. 18:12
kilden bruker

stemmer
1

Jeg vil anbefale en av to tilnærminger. Først investere i Power fra Sybase. Enterprise Edition. Den lar deg designe Fysiske datamodels, og en hel masse mer. Men det kommer med et depot som gjør det mulig å sjekke inn dine modeller. Hver ny sjekk i kan være en ny versjon, den kan sammenligne en versjon til en annen versjon og til og med hva som er i databasen på den tiden. Det vil da presentere en liste over alle forskjell og spør som skal flyttes ... og det bygger manuset å gjøre det. Det er ikke billig, men det er et godt kjøp på to ganger prisen, og det er avkastningen er ca 6 måneder.

Den andre tanken er å slå på DDL revisjon (fungerer i Oracle). Dette vil skape en tabell med hver endring du gjør. Hvis du spør de endringer fra tidsstempel siste du flyttet databaseendringer å prod til akkurat nå, vil du ha en ordnet liste over alt du har gjort. Noen hvor punktene for å eliminere null-sum forandrer lignende opprette tabellen foo; etterfulgt av rullebordet foo; og du kan enkelt lage en mod script. Hvorfor beholde endringene i en wiki, som er dobbelt arbeid. La databasen spore dem for deg.

Svarte 26/09/2008 kl. 17:53
kilden bruker

stemmer
1

To bok-anbefalinger: "refactoring Databaser" av Ambler og Sadalage og "Agile Database Techniques" av Ambler.

Noen nevnte Rails Migrations. Jeg tror de fungerer fint, selv utenfor Rails applikasjoner. Jeg brukte dem på en ASP applikasjon med SQL Server som vi var i ferd med å flytte til Rails. Du sjekker migrasjon scripts seg inn i VCS. Her er et innlegg av Pragmatic Dave Thomas om emnet.

Svarte 22/09/2008 kl. 18:17
kilden bruker

stemmer
1

I fravær av en VCS for bord endringene jeg har vært å logge dem i en wiki. Minst da kan jeg se når og hvorfor det ble endret. Det er langt fra perfekt som ikke alle gjør det, og vi har flere produktversjoner i bruk, men bedre enn ingenting.

Svarte 01/09/2008 kl. 07:29
kilden bruker

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