Versjons SQL Server-database

stemmer
292

Jeg ønsker å få mine databaser under versjonskontroll. Er det noen som har noen råd eller anbefalte artikler for å få meg i gang?

Jeg vil alltid ønske å ha minst noen data i det (som alumb nevner: brukertyper og administratorer). Jeg vil også ofte ha en stor samling av genererte testdata for ytelsesmålinger.

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


29 svar

stemmer
170

Martin Fowler skrev min favoritt artikkel om emnet, http://martinfowler.com/articles/evodb.html . Jeg velger å ikke sette skjema dumper under versjonskontroll som alumb og andre foreslår fordi jeg ønsker en enkel måte å oppgradere min produksjon database.

For en webapplikasjon hvor jeg vil ha en enkelt produksjon database eksempel, jeg bruker to teknikker:

Database Oppgraderings Scripts

En sekvens database oppgradering skript som inneholder DDL er nødvendig for å bevege skjemaet fra versjonen N til N + 1. (Disse går i versjonskontrollsystemet.) En _version_history_ tabellen, noe som

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

får en ny oppføring hver gang en oppgradering skript kjøres som tilsvarer den nye versjonen.

Dette sikrer at det er lett å se hvilken versjon av databaseskjema eksisterer og at databaseoppgraderingsskript kjøres kun en gang. Igjen, dette er ikke database dumper. Snarere representerer hver script de endringer som er nødvendige for å flytte fra én versjon til den neste. De er skriptet som du bruker på din produksjonsdatabasen å "oppgradere" den.

Utvikler Sandbox Synkronisering

  1. Et skript til backup, rense og krympe en produksjon database. Kjør dette etter hver oppgradering til produksjons DB.
  2. Et skript for å gjenopprette (og justere om nødvendig) backup på en utviklers arbeidsstasjon. Hver utvikler kjører dette skriptet etter hver oppgradering til produksjons DB.

En påminnelse: Mine automatiserte tester kjøres mot en skjema korrekt, men tom database, så dette rådet vil ikke helt passer dine behov.

Svarte 02/08/2008 kl. 17:33
kilden bruker

stemmer
42

Red Gate SQL Sammenlign produkt ikke bare lar deg gjøre objektnivå sammenligninger, og generere endre skript fra det, men det gjør det også mulig å eksportere databaseobjekter i et mappehierarki organisert av objekttype, med en [objekt] sql skapelse script per objekt i disse katalogene. Den objekttype hierarki er som dette:

\ Funksjoner
\ Security
\ Security \ Roller
\ Security \ skjemaer
\ Security \ Users
\ lagrede prosedyrer
\ Bord

Hvis du dumpe skript til samme rotkatalogen etter at du gjør endringer, kan du bruke denne til å oppdatere SVN repo, og holde en løpende historie hvert objekt individuelt.

Svarte 26/08/2008 kl. 07:23
kilden bruker

stemmer
39

Dette er en av de "harde problemer" rundt utvikling. Så vidt jeg vet er det ingen perfekte løsninger.

Hvis du bare trenger å lagre databasestrukturen og ikke dataene du kan eksportere database som SQL-spørringer. (I Enterprise Manager: Høyreklikk på databasen -> generere SQL-script jeg anbefaler at du stiller "opprette en fil per objekt" i kategorien alternativer.) Du kan da begår disse tekstfiler til svn og gjøre bruk av svn er diff og logging funksjoner.

Jeg har dette bundet sammen med en batch-script som tar et par parametere og setter opp databasen. Jeg har også lagt noen flere spørsmål som kommer inn standard data som bruker og admin-bruker. (Hvis du vil ha mer informasjon om dette, legger ut noe, og jeg kan sette manuset sted tilgjengelig)

Hvis du trenger å holde alle data også, anbefaler jeg å holde en sikkerhetskopi av databasen og bruke Redgate ( http://www.red-gate.com/ ) produkter å gjøre sammenligninger. De er ikke billige, men de er verdt hver krone.

Svarte 01/08/2008 kl. 19:28
kilden bruker

stemmer
37

Først må du velge den versjonen kontrollsystem som er riktig for deg:

  • Sentralisert Versjonskontroll system - et standardsystem der brukerne sjekke ut / sjekk inn før / etter de arbeider på filene, og filene blir holdt i en enkelt sentral server

  • Distribuert versjonskontroll system - et system der depotet blir klonet, og hver klone er faktisk full backup av depotet, så hvis noen server krasjer, så noen klonet depot kan brukes til å gjenopprette det Etter å ha valgt riktig system for dine behov , må du setup depotet som er kjernen i hver versjonskontrollsystem Alt dette er forklart i følgende artikkel: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-kontroll-basics /

Etter å ha satt opp et depot, og i tilfelle av en sentral versjonskontrollsystem en arbeidsmappe, kan du lese denne artikkelen . Den viser hvordan du setter opp kildekontroll i et utviklingsmiljø ved hjelp av:

  • SQL Server Management Studio via MSSCCI leverandør,

  • Visual Studio og SQL Server Dataverktøy

  • En tredje part verktøy ApexSQL kildekontroll
Svarte 24/06/2015 kl. 10:36
kilden bruker

stemmer
22

Her på Red Gate tilbyr vi et verktøy, SQL kildekontroll , som bruker SQL Sammenlign teknologi for å koble databasen med en TFS eller SVN repository. Dette verktøyet integreres i SSMS og lar deg arbeide som du normalt ville, bortsett fra at det nå lar du forplikte objektene.

For en vandringer basert tilnærming (mer egnet for automatisert utrulling), tilbyr vi ReadyRoll , som skaper og forvalter et sett med inkrementelle skript som Visual Studio prosjekt.

I SQL kildekontroll er det mulig å spesifisere statiske datatabeller. Disse lagres i kildekontroll som INSERT-setninger.

Hvis du snakker om testdata, vil vi anbefale at du enten generere testdata med et verktøy eller via en post-distribusjon script du definerer, eller du bare gjenopprette en produksjon backup til dev miljø.

Svarte 01/07/2010 kl. 09:10
kilden bruker

stemmer
20

Du ønsker kanskje å se på Liquibase ( http://www.liquibase.org/ ). Selv om du ikke bruker verktøyet selv den håndterer begrepene database endringsledelse eller ommøblerer ganske bra.

Svarte 16/09/2008 kl. 18:16
kilden bruker

stemmer
17

En for alle som har anbefalt Redgate verktøy, med en ekstra anbefaling og en påminnelse.

SqlCompare har også en skikkelig dokumentert API: så du kan for eksempel skrive en konsoll app som synkroniserer mappen kilde kontrollert skript med en CI integrasjonstesting database på checkin, slik at når noen sjekker i en endring i skjema fra deres scripts mappen det automatisk distribueres sammen med matchende applikasjonskoden endres. Dette bidrar til å lukke gapet med utviklere som er glemsk om formeringsmateriale endringer i deres lokale db opp til en felles utvikling DB (omtrent halvparten av oss, tror jeg :)).

En påminnelse er at med en skriptløsning eller på annen måte, de Redgate verktøy er tilstrekkelig glatt at det er lett å glemme SQL realiteter som ligger til grunn abstraksjon. Hvis du endre navn på alle kolonnene i en tabell, har SqlCompare ingen måte å kartlegge de gamle kolonnene til nye kolonner og vil slippe alle dataene i tabellen. Det vil generere advarsler, men jeg har sett folk klikker forbi det. Det er en generell poenget her verdt å gjøre, tror jeg, at du bare kan automatisere DB versjonskontroll og oppgradere så langt - de abstraksjoner er veldig lekk.

Svarte 15/10/2008 kl. 09:44
kilden bruker

stemmer
14

Med VS 2010, bruker Database prosjektet.

  1. Script ut databasen
  2. Gjør endringer i skript eller direkte på din db-server
  3. Synkronisere ved hjelp av data> Schema Sammenlign

Gjør en perfekt DB versjons løsning, og gjør synkronisering DB er en lek.

Svarte 25/02/2011 kl. 20:18
kilden bruker

stemmer
14

Vi bruker DBGhost å forvalte vår SQL database. Deretter kan du sette skript for å bygge en ny database i versjonskontroll, og det vil heller bygge en ny database, eller oppgradere eksisterende database til skjemaet i versjonskontroll. På den måten trenger du ikke å bekymre deg for å skape endring skript (selv om du kan fortsatt gjøre det, hvis du for eksempel ønsker å endre datatypen til en kolonne, og trenger å konvertere data).

Svarte 07/08/2008 kl. 21:12
kilden bruker

stemmer
12

Det er en god måte å spare database skript i versjonskontroll med endrings skript, slik at du kan oppgradere noen database du har. Også kan det være lurt å spare skjemaer for ulike versjoner, slik at du kan lage en hel database uten å måtte bruke alle endrings skript. Håndtering skriptene bør være automatisert, slik at du ikke trenger å gjøre manuelt arbeid.

Jeg tror det er viktig å ha en egen database for alle utviklere, og ikke bruke en felles database. På den måten kan utviklere lage testtilfeller og utviklingsfaser uavhengig av andre utviklere.

Den automatisering verktøyet skal ha midler for håndtering database metadata, som forteller hva databaser er i hvilken tilstand av utvikling og hvilke tabeller inneholde versjonskontrollerbare data og så videre.

Svarte 24/09/2008 kl. 06:11
kilden bruker

stemmer
11

Du kan også se på en vandringer løsning. Disse lar deg angi databaseskjemaet i C # -kode, og rulle database versjon opp og ned ved hjelp MSBuild.

Jeg er for tiden bruker DbUp , og det har vært jobbet godt.

Svarte 06/08/2008 kl. 22:51
kilden bruker

stemmer
11

Du nevnte ikke noen nærmere detaljer om målet ditt miljø eller begrensninger, så dette kan ikke være helt aktuelt ... men hvis du leter etter en måte å effektivt spore en utvikling DB skjema og er ikke negative til ideen om å bruke Ruby, Active vandringer er rett opp smug.

Migreringer auto definere databasetransformasjoner ved hjelp av et Ruby DSL; hver transformasjon kan brukes eller (vanligvis) rullet tilbake, slik at du kan hoppe til en annen versjon av DB skjema på et gitt tidspunkt. Filen definere disse transformasjoner kan sjekkes inn i versjonskontroll som hvilken som helst annen del av kildekoden.

Fordi overføringer er en del av Active , de vanligvis finner anvendelse i full stabel Skinner applikasjoner; Du kan imidlertid bruke Active uavhengig av Rails med minimal innsats. Se her for en mer detaljert behandling av å bruke AR vandringer utenfor Rails.

Svarte 02/08/2008 kl. 17:54
kilden bruker

stemmer
9

Hver database bør være under kildekoden kontroll. Det som mangler er et verktøy for automatisk script alle databaseobjekter - og "konfigurasjon data" - til fil, som deretter kan legges til noen kilde kontrollsystem. Hvis du bruker SQL Server, så min løsning er her: http://dbsourcetools.codeplex.com/ . Ha det gøy. - Nathan.

Svarte 07/07/2009 kl. 12:58
kilden bruker

stemmer
8

Det er enkelt.

  1. Når basen prosjektet er ferdig så må du opprette fulle database script. Dette skriptet er forpliktet til SVN. Det er første versjon.

  2. Etter at alle utviklere skaper endring skript (ALTER ..., nye bord, sprocs, etc).

  3. Når du trenger gjeldende versjon bør du utføre alle nye endrings skript.

  4. Når programmet er sluppet til produksjon så du går tilbake til en (men da vil det være etterfølgende versjon selvfølgelig).

Nant vil hjelpe deg til å utføre disse endrings skript. :)

Og husk. Alt fungerer fint når det er disiplin. Hver gang når databasen endringen er forpliktet deretter tilsvarende funksjoner i kode er forpliktet også.

Svarte 16/05/2009 kl. 11:31
kilden bruker

stemmer
7

For å gjøre dump til en kildekode kontrollsystem som litt raskere, kan du se hvilke objekter som har endret seg siden forrige gang ved å bruke versjonsinformasjonen i sysobjects.

Oppsett: Lag en tabell i hver database du ønsker å sjekke trinnvis å holde versjonsinformasjonen fra forrige gang du sjekket det (tom på første kjøring). Fjerne denne tabellen hvis du ønsker å re-skanne hele datastruktur.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Normal driftsmodus: Du kan ta resultatene fra denne sql, og generere SQL-skript for bare de du er interessert i, og sette dem inn i en kilde kontroll av ditt valg.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Merk: Hvis du bruker et ikke-standard sortering i noen av databasene, må du erstatte /* COLLATE */med database sortering. dvsCOLLATE Latin1_General_CI_AI

Svarte 24/09/2008 kl. 12:53
kilden bruker

stemmer
7

Fordi vår app har å jobbe på tvers av flere RDBMSs, lagrer vi vår skjemadefinisjonen i versjonskontroll ved hjelp av databasen nøytrale Torque format (XML). Vi har også versjon-kontrollere referansedata for vår database i XML-format som følger (der "forhold" er en av de referansetabeller):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Vi bruker da hjemmelaget verktøy for å generere skjemaet oppgradering og referansedata oppgradere skript som kreves for å gå fra versjon X av databasen til versjon X + 1.

Svarte 24/09/2008 kl. 05:49
kilden bruker

stemmer
7

Hvis du har en liten database og du vil versjonen hele greia, denne batch script kan hjelpe. Det løsner, komprimerer, og sjekker en MSSQL database MDF fil til Subversion.

Hvis du stort sett vil versjonen ditt skjema og bare ha en liten mengde referansedata, kan du muligens bruke Subsonic Migrations å håndtere det. Fordelen er at du enkelt kan overføre opp eller ned til en bestemt versjon.

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

stemmer
6

Jeg skrev dette app for en stund siden, http://sqlschemasourcectrl.codeplex.com/ som vil skanne MSFT SQL db så ofte du vil, og automatisk dumpe gjenstander (tabeller, views, procs, funksjoner, sql innstillinger) i SVN. Fungerer som en sjarm. Jeg bruker den med Unfuddle (som tillater meg å få varsler om innsjekk)

Svarte 23/09/2010 kl. 02:35
kilden bruker

stemmer
6

Vi hadde behov for å versjonen vår SQL database etter at vi flyttet til en x64-plattform og våre gamle versjonen brøt med migrasjon. Vi skrev en C # applikasjon som brukes Sqldmo å kartlegge alle SQL-objekter til en mappe:

                Rot
                    Server navn
                       databasenavn
                          skjemaobjekter
                             Database utløser *
                                .ddltrigger.sql
                             funksjoner
                                ..function.sql
                             Sikkerhet
                                Roller
                                   Søknad Roller
                                      .approle.sql
                                   Database Roller
                                      .role.sql
                                skjemaer *
                                   .schema.sql
                                brukere
                                   .user.sql
                             Oppbevaring
                                Fullstendig tekst Kataloger *
                                   .fulltext.sql
                             lagrede prosedyrer
                                ..proc.sql
                             synonymer *
                                .synonym.sql
                             tabeller
                                ..table.sql
                                begrensninger
                                   ... chkconst.sql
                                   ... defconst.sql
                                indekser
                                   ... index.sql
                                Keys
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                Triggers
                                   ... trigger.sql
                             typer
                                Brukerdefinerte datatyper
                                   ..uddt.sql
                                XML Schema samlinger *
                                   ..xmlschema.sql
                             Visninger
                                ..view.sql
                                indekser
                                   ... index.sql
                                Triggers
                                   ... trigger.sql

Søknaden vil deretter sammenligne den nyskrevne versjon til versjon lagret i SVN og hvis det var forskjeller det ville oppdatere SVN. Vi bestemte at å kjøre prosessen en gang i natt var nok siden vi ikke gjør at mange endringer i SQL. Det tillater oss å spore endringer i alle objektene vi bryr oss om, pluss det tillater oss å gjenoppbygge vår fulle skjema i tilfelle av et alvorlig problem.

Svarte 09/10/2008 kl. 14:54
kilden bruker

stemmer
6

Vi lagrer ikke databaseskjema, vi lagre endringer i databasen. Det vi gjør er å lagre skjema endringer slik at vi bygger en endring skript for noen versjon av databasen og bruke den til våre kunders databaser. Jeg skrev en database verktøy app som blir distribuert med vår hovedprogram som kan lese at manus og vet hvilke oppdateringer som må brukes. Den har også nok vett til å oppdatere utsikt og lagrede prosedyrer som trengs.

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

stemmer
5

Jeg er enig med ESV svar og for at nøyaktig grunnen til at jeg startet et lite prosjekt en stund tilbake for å opprettholde databaseoppdateringer i en svært enkel fil som deretter kan opprettholdes i lang side ut kildekoden. Den tillater enkle oppdateringer til utviklere samt UAT og Production. Verktøyet fungerer på, men SQL Server og MySQL.

Noen prosjekt funksjoner:

  • Lar skjemaendringer
  • Lar verdi treet befolkningen
  • Tillater separate testdata innsatser for f.eks. UAT
  • Gir mulighet for tilbakestilling (ikke automatisert)
  • Opprettholder støtte for SQL server og MySQL
  • Har muligheten til å importere din eksisterende database til versjonskontroll med en enkel kommando (sql server bare ... jobber fortsatt med mysql)

Koden ligger på Google Code. Sjekk ut Google-koden for litt mer informasjon

http://code.google.com/p/databaseversioncontrol/

Svarte 24/02/2011 kl. 18:28
kilden bruker

stemmer
5

Vi begynte bare å bruke Team Foundation Server. Hvis databasen er mellomstor, deretter Visual Studio har noen fine prosjektintegrasjoner med bygget i sammenligningen, data sammenligne, database refactoring verktøy, database testing rammeverk, og til og med data generasjons verktøy.

Men, det betyr modellen ikke passer veldig store eller tredjeparts databaser (som krypterer objekter) veldig godt. Så, hva vi har gjort er å lagre bare våre tilpassede stedene. Visual Studio / Team Foundation Server fungerer veldig bra for det.

TFS Database sjef bue. blog

MS TFS nettstedet

Svarte 22/08/2008 kl. 17:13
kilden bruker

stemmer
5

Den typiske løsningen er å dumpe databasen som nødvendig og backup disse filene.

Avhengig av utviklingsplattform, kan det være opensource plugins tilgjengelig. Rullende din egen kode for å gjøre det er vanligvis ganske trivielt.

Merk: Det kan være lurt å ta sikkerhetskopi av databasen dump stedet for å sette det inn i versjonskontroll. Filene kan få enorme fort i versjonskontroll, og føre til at hele kilde kontrollsystem for å bli treg (Jeg minner om en CVS skrekkhistorie for øyeblikket).

Svarte 03/08/2008 kl. 01:49
kilden bruker

stemmer
4

Jeg også bruker en versjon i databasen lagret via databasen utvidede egenskaper familie av prosedyrer. Min søknad har skript for hver versjon trinn (ie. Flytte 1,1 til 1,2). Når utplassert, ser det på den gjeldende versjonen, og kjører deretter skriptene en etter en til den når den siste app-versjonen. Det er ingen skript som har den rette 'endelige' versjonen, selv distribuere på en ren DB gjør distribuere via en rekke oppgraderingstrinn.

Nå hva jeg gjerne legge til at jeg har sett to dager siden en presentasjon på MS campus om nye og kommende VS DB-utgaven. Presentasjonen ble fokusert spesielt på dette temaet, og jeg ble blåst ut av vannet. Du bør definitivt sjekke det ut, de nye anleggene er fokusert på å holde skjema definisjon i T-SQL-skript (skaper), en runtime delta motor for å sammenligne distribusjon skjema med definert skjema og gjøre de delta endrer og integrasjon med kildekode integrasjon, opp til og med MSBuild kontinuerlig integrasjon for automatiserte bygge dråper. Dråpen vil inneholde en ny filtype, de .dbschema filer, som kan tas til utplasseringssted og et kommandolinje verktøy kan gjøre selve 'deltaer' og kjøre distribusjon. Jeg har en bloggpost om dette emnet med koblinger til VSDE nedlastinger, bør du sjekke dem ut: http://rusanu.com/2009/05/15/version-control-and-your-database/

Svarte 15/05/2009 kl. 19:26
kilden bruker

stemmer
4

For en stund siden fant jeg en VB bas modul som brukes DMO og VSS objekter for å få en hel db manus av og til VSS. Jeg gjorde det til en VB Script og postet den her . Du kan enkelt ta ut VSS samtaler og bruke DMO ting å generere alle skript, og deretter ringe SVN fra samme batch fil som kaller opp VBScript å sjekke dem inn?

Dave J

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

stemmer
3

Dens en svært gammel spørsmålet, men mange prøver å løse dette selv nå. Alt de trenger å gjøre er å undersøke om Visual Studio Database Prosjekter. Uten dette, ser noen database utvikling svært svak. Fra koden organisering til distribusjon til versjonskontroll, forenkler det alt.

Svarte 23/06/2015 kl. 11:26
kilden bruker

stemmer
2

Sjekk ut DBGhost http://www.innovartis.co.uk/ . Jeg har brukt i en automatisert måte i 2 år nå, og det fungerer bra. Det gjør vår DB bygger å skje mye som en Java eller C bygge skjer, bortsett fra databasen. Du vet hva jeg mener.

Svarte 02/11/2009 kl. 22:17
kilden bruker

stemmer
2

I min erfaring løsningen er todelt:

  1. Du trenger for å håndtere endringer i utviklingen database som er gjort av flere utviklere under utvikling.

  2. Du trenger for å håndtere databaseoppgraderinger i kundenes nettsteder.

For å håndtere # 1 trenger du en sterk database diff / merge verktøyet. Det beste verktøyet skal kunne utføre automatisk fletting så mye som mulig samtidig som du kan løse ubehandlet konflikter manuelt.

Den perfekte verktøy skal håndtere flette operasjonene ved å bruke en 3-veis flette algoritme som tar hensyn til de endringer som er gjort i deres databasen og MINE databasen, i forhold til underlaget databasen.

Jeg skrev et kommersielt verktøy som gir manuell fletting støtte for SQLite databaser, og jeg er for tiden å legge til støtte for 3-veis merge algoritmen for SQLite. Sjekk det ut på http://www.sqlitecompare.com

For å håndtere # 2 vil du trenge en oppgradering rammeverket på plass.

Den grunnleggende ideen er å utvikle en automatisk oppgradering rammeverk som vet hvordan du oppgraderer fra en eksisterende SQL skjema til nyere SQL skjema og kan bygge en oppgradering for hver eksisterende DB installasjon.

Sjekk ut min artikkel om emnet i http://www.codeproject.com/KB/database/sqlite_upgrade.aspx å få en generell ide om hva jeg snakker om.

Lykke til

Liron Levi

Svarte 06/08/2009 kl. 10:28
kilden bruker

stemmer
1

Jeg vil foreslå å bruke sammenligning verktøy for å improvisere et versjonskontrollsystem for databasen. Et godt alternativ er xSQL Schema Sammenlign og xSQL data Sammenlign .

Nå, hvis målet ditt er å ha bare databasens skjema under versjonskontroll kan du bare bruke xSQL Schema Sammenlign for å generere xSQL Snapshots av skjemaet og legge disse filene i versjonskontroll. Enn å gå tilbake eller oppdatere til en bestemt versjon bare sammenligne den gjeldende versjonen av databasen med snapshot for destinasjonen versjon.

Akk, hvis du ønsker å ha data under versjonskontroll i tillegg, kan du bruke xSQL data Sammenlign å generere endre skript for deg databasen og legge til .SQL filer i versjonskontroll. Du kan deretter utføre disse skriptene for å gå tilbake / oppdatering til alle versjoner du vil. Husk at for 'revert' funksjonaliteten du trenger for å generere endre skript som når henrettet vil gjøre Versjon 3 det samme som versjon 2 og for 'update' funksjonalitet, må du generere endre skript som gjør det motsatte.

Til slutt, med noen grunnleggende batch programmering kan du automatisere hele prosessen ved hjelp av kommandolinje versjoner av xSQL Schema Sammenlign og xSQL data Sammenlign

Disclaimer: Jeg er tilknyttet xSQL.

Svarte 10/01/2017 kl. 16:16
kilden bruker

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