Database di versioni di SQL Server


315

Voglio mettere i miei database sotto controllo di versione. Qualcuno ha qualche consiglio o articoli consigliati per iniziare?

Avrò sempre bisogno di avere almeno alcuni dati lì dentro (come menzione alumb : tipi di utenti e amministratori). Spesso desidero anche una vasta raccolta di dati di test generati per le misurazioni delle prestazioni.


Dai anche un'occhiata a questo white paper; La guida definitiva al controllo della versione del database www3.dbmaestro.com/…
DBAstep

Risposte:


179

Martin Fowler ha scritto il mio articolo preferito sull'argomento, http://martinfowler.com/articles/evodb.html . Ho scelto di non mettere i dump dello schema sotto controllo di versione come inutili e altri suggeriscono perché voglio un modo semplice per aggiornare il mio database di produzione.

Per un'applicazione Web in cui avrò una singola istanza del database di produzione, utilizzo due tecniche:

Script di aggiornamento del database

Script di aggiornamento del database di sequenza che contengono il DDL necessario per spostare lo schema dalla versione N a N + 1. (Questi vanno nel tuo sistema di controllo della versione.) Una tabella _version_history_, qualcosa del genere

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

ottiene una nuova voce ogni volta che viene eseguito uno script di aggiornamento che corrisponde alla nuova versione.

Ciò garantisce che sia facile vedere quale versione dello schema del database esiste e che gli script di aggiornamento del database vengono eseguiti solo una volta. Ancora una volta, questi non sono dump del database. Piuttosto, ogni script rappresenta le modifiche necessarie per passare da una versione alla successiva. Sono lo script che si applica al database di produzione per "aggiornarlo".

Sincronizzazione sandbox per sviluppatori

  1. Uno script per il backup, la sanificazione e la riduzione di un database di produzione. Eseguire questo dopo ogni aggiornamento al DB di produzione.
  2. Uno script per ripristinare (e modificare, se necessario) il backup sulla workstation di uno sviluppatore. Ogni sviluppatore esegue questo script dopo ogni aggiornamento al DB di produzione.

Un avvertimento: i miei test automatici vengono eseguiti su un database corretto ma vuoto, quindi questo consiglio non si adatta perfettamente alle tue esigenze.


16
La versione che controlla gli script di schema completi è molto utile a scopo di riferimento. Ad esempio, è impossibile vedere cosa è stato esattamente modificato in una procedura memorizzata guardando l'istruzione ALTER PROCEDURE.
Constantin,

12
Il dump (e il versioning) dell'intero schema DB dopo l'esecuzione di nuovi script di aggiornamento è un buon modo per rendere disponibili le informazioni anche ad altri strumenti nel processo di compilazione / distribuzione. Inoltre, avere lo schema completo in uno script significa essere in grado di "girare" un nuovo database senza passare attraverso tutti i passaggi della migrazione. Inoltre, rende possibile la differenza tra la versione corrente e le versioni precedenti accumulate.
mlibby,

2
Stai dicendo che hai messo gli script di aggiornamento nel controllo del codice sorgente, non hai inserito quelli di rollback lì?
AK,

9
Ho l'abitudine di mantenere uno script di creazione e rilascio completo, nonché script delta per l'aggiornamento di istanze di db esistenti aggiornate. Entrambi entrano nel controllo versione. Gli script delta sono denominati in base ai numeri di revisione. In questo modo è facile automatizzare le patch db con uno script di aggiornamento.
nikc.org,

1
La risposta di @ nikc.org, oltre agli hook post-commit per l'automazione.
Silviu-Marian,

45

Il prodotto SQL Compare di Red Gate non solo ti consente di fare confronti a livello di oggetto e di generare script di modifica da questo, ma ti consente anche di esportare i tuoi oggetti di database in una gerarchia di cartelle organizzata per tipo di oggetto, con una creazione [nome oggetto] .sql script per oggetto in queste directory. La gerarchia del tipo di oggetto è così:

\ Funzioni
\ Sicurezza
\ Sicurezza \ Ruoli
\ Sicurezza \ Schemi
\ Sicurezza \ Utenti
\ Stored procedure
\ Tabelle

Se si esegue il dump degli script nella stessa directory principale dopo aver apportato modifiche, è possibile utilizzarlo per aggiornare il repository SVN e mantenere una cronologia di esecuzione di ciascun oggetto singolarmente.


6
Abbiamo appena rilasciato SQL Source Control, che integra il comportamento SQL Compare descritto in SSMS e collega a SVN e TFS. Ho aggiunto una risposta separata a questa domanda che descrive in modo più dettagliato cosa fa. red-gate.com/products/SQL_Source_Control/index.htm
David Atkinson

39

Questo è uno dei "problemi difficili" che circondano lo sviluppo. Per quanto ne so non ci sono soluzioni perfette.

Se è necessario solo archiviare la struttura del database e non i dati, è possibile esportare il database come query SQL. (in Enterprise Manager: fare clic con il pulsante destro del mouse sul database -> Genera script SQL. Consiglio di impostare "Crea un file per oggetto" nella scheda delle opzioni) È quindi possibile eseguire il commit di questi file di testo su svn e utilizzare le funzioni diff e logging di svn.

Ho questo legato con uno script Batch che accetta un paio di parametri e imposta il database. Ho anche aggiunto alcune query aggiuntive che inseriscono dati predefiniti come i tipi di utente e l'utente amministratore. (Se vuoi maggiori informazioni su questo, pubblica qualcosa e posso mettere lo script in qualche posto accessibile)

Se è necessario conservare anche tutti i dati, si consiglia di tenere un backup del database e di utilizzare i prodotti Redgate ( http://www.red-gate.com/ ) per effettuare i confronti. Non costano poco, ma valgono ogni centesimo.


1
per quanto riguarda i dati: è possibile utilizzare OffScale DataGrove per salvare le versioni dell'intero DB (dati inclusi). Successivamente puoi usarlo per generare due copie virtuali del tuo DB che possono essere confrontate con il prodotto di red-gate. Inoltre risparmia la necessità di generare dati di test: puoi semplicemente salvare le versioni del DB per abbinare i diversi casi di test (di nuovo, copie complete e virtuali dell'intero DB)
Taichman,

1
Come si determina quale ordine eseguire gli script del database se si utilizza l'opzione "un file per oggetto"?
Jamie Kitson,

@Taichman: DataGrove non sembra supportare il server SQL e come tale non ha rilevanza per la domanda.
Neolisk,

38

Innanzitutto, devi scegliere il sistema di controllo della versione adatto a te:

  • Sistema di controllo versione centralizzato - un sistema standard in cui gli utenti eseguono il check out / check in prima / dopo aver lavorato sui file e i file vengono conservati in un singolo server centrale

  • Sistema di controllo della versione distribuita - un sistema in cui il repository viene clonato e ogni clone è in realtà il backup completo del repository, quindi se un server si arresta in modo anomalo, è possibile utilizzare qualsiasi repository clonato per ripristinarlo Dopo aver scelto il sistema adatto alle proprie esigenze , dovrai configurare il repository che è il cuore di ogni sistema di controllo delle versioni Tutto questo è spiegato nel seguente articolo: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -Source-control-basics /

Dopo aver impostato un repository e nel caso di un sistema di controllo versione centrale una cartella funzionante, puoi leggere questo articolo . Mostra come configurare il controllo del codice sorgente in un ambiente di sviluppo usando:

  • SQL Server Management Studio tramite il provider MSSCCI,

  • Visual Studio e SQL Server Data Tools

  • Uno strumento di terze parti ApexSQL Source Control

24

Qui a Red Gate offriamo uno strumento, SQL Source Control , che utilizza la tecnologia SQL Compare per collegare il database con un repository TFS o SVN. Questo strumento si integra in SSMS e ti consente di lavorare come faresti normalmente, tranne per il fatto che ora ti consente di eseguire il commit degli oggetti.

Per un approccio basato sulle migrazioni (più adatto per le distribuzioni automatizzate), offriamo SQL Change Automation (precedentemente chiamato ReadyRoll), che crea e gestisce un set di script incrementali come progetto di Visual Studio.

In SQL Source Control è possibile specificare tabelle di dati statici. Questi sono memorizzati nel controllo del codice sorgente come istruzioni INSERT.

Se stai parlando di dati di test, ti consigliamo di generare i dati di test con uno strumento o tramite uno script post-distribuzione definito o di ripristinare semplicemente un backup di produzione nell'ambiente di sviluppo.


Prodotto interessante (un po 'di spazio nel mercato) ma i delta memorizzati come "CREATE ..." mi spaventano. Come stai ramificando / fondendo?
annakata,

1
Memorizziamo le definizioni degli oggetti come CREATE, ma se si ottiene "più recenti" o, ad esempio, si utilizza SQL Compare Pro per generare script di sincronizzazione, questi vengono modificati con i comandi appropriati, come ALTER. Per ramificare o unire, useresti semplicemente il tuo sistema di controllo del codice sorgente nello stesso modo in cui lo fai attualmente.
David Atkinson,

Questa risposta è un duplicato della risposta di Dane pubblicata due anni prima.
WonderWorker,

È una risposta diversa. SQL Compare non controlla i database di versione, mentre SQL Source Control è stato progettato appositamente per questo.
David Atkinson,

21

Potresti voler guardare Liquibase ( http://www.liquibase.org/ ). Anche se non si utilizza lo strumento stesso, gestisce abbastanza bene i concetti di gestione delle modifiche al database o refactoring.


Usiamo Liquibase in 5 team distribuiti su un unico ramo per la consegna continua e funziona alla grande. Abbiamo 10+ applicazioni di database installate su molti ambienti diversi. Lo usiamo per gestire schemi, indicizzazione, partizionamento, codice, dati di ricerca, gruppi e autorizzazioni di gruppo. Lo usiamo per Oracle, Postgresql e MSSQL.
Peter Henell,

Se capisco correttamente in base all'introduzione, è necessario che tu conosca un linguaggio XML proprietario per dichiarare i tuoi oggetti anziché SQL? Non è un fan.
JDPeckham,

19

+1 per tutti coloro che hanno raccomandato gli strumenti RedGate, con una raccomandazione aggiuntiva e un avvertimento.

SqlCompare ha anche un'API decentemente documentata: quindi puoi, ad esempio, scrivere un'app console che sincronizza la cartella degli script controllati dal codice sorgente con un database di test di integrazione CI al momento del check-in, in modo che quando qualcuno accede a una modifica allo schema dalla cartella degli script viene distribuito automaticamente insieme alla modifica del codice dell'applicazione corrispondente. Questo aiuta a colmare il divario con gli sviluppatori che si dimenticano di propagare le modifiche nel loro db locale fino a un DB di sviluppo condiviso (circa la metà di noi, penso :)).

Un avvertimento è che con una soluzione con script o in altro modo, gli strumenti RedGate sono sufficientemente fluidi da dimenticare facilmente le realtà SQL sottostanti l'astrazione. Se si rinomina tutte le colonne in una tabella, SqlCompare non ha modo di mappare le vecchie colonne alle nuove colonne e eliminerà tutti i dati nella tabella. Genererà avvisi ma ho visto persone fare clic su di esso. C'è un punto generale qui degno di nota, penso, che fino ad ora puoi solo automatizzare il versioning e l'aggiornamento del DB - le astrazioni sono molto trapelate.


Quindi dovrebbe esserci un sistema che tiene traccia delle colonne che stai modificando e ricorda le mappature dai vecchi nomi delle colonne ai nuovi nomi delle colonne.
Silvercode

Vale la pena ricordare che per le modifiche al database che hanno ambiguità (e quindi necessitano di un elemento di "intento di sviluppatore"), una soluzione basata sulle migrazioni è la soluzione appropriata. Redgate ora ha ReadyRoll che soddisfa questo approccio al versioning.
David Atkinson,

15

Usiamo DBGhost per gestire il nostro database SQL. Quindi inserisci gli script per creare un nuovo database nel controllo della versione e creerà un nuovo database o aggiornerà qualsiasi database esistente allo schema nel controllo della versione. In questo modo non devi preoccuparti di creare script di modifica (anche se puoi ancora farlo, se ad esempio vuoi cambiare il tipo di dati di una colonna e devi convertire i dati).


Ho usato DbGhost per 10 anni e non mi ha mai deluso. Il supporto che forniscono è secondo a nessuno
penderi

15

Con VS 2010, utilizzare il progetto Database.

  1. Crea script per il tuo database
  2. Apporta modifiche agli script o direttamente sul tuo server db
  3. Sincronizzazione utilizzando Dati> Confronto schema

Crea una soluzione perfetta per il controllo delle versioni dei DB e semplifica la sincronizzazione dei DB.


2
Sì, ma sfortunatamente devi ricordarti di "generare script" ogni volta. Se si aggiorna direttamente il database, si perde la possibilità di generare lo script di aggiornamento per quel delta. Se solo i progetti di database avessero alcune funzionalità integrate per il controllo delle versioni.
Jez,

13

È un buon approccio salvare gli script del database nel controllo versione con gli script di modifica in modo da poter aggiornare qualsiasi database che si possiede. Inoltre, potresti voler salvare schemi per versioni diverse in modo da poter creare un database completo senza dover applicare tutti gli script di modifica. La gestione degli script dovrebbe essere automatizzata in modo da non dover eseguire lavori manuali.

Penso che sia importante avere un database separato per ogni sviluppatore e non usare un database condiviso. In questo modo gli sviluppatori possono creare casi di test e fasi di sviluppo indipendentemente dagli altri sviluppatori.

Lo strumento di automazione dovrebbe avere i mezzi per gestire i metadati del database, che indica quali database si trovano in quale stato di sviluppo e quali tabelle contengono dati controllabili dalla versione e così via.


12

Puoi anche cercare una soluzione per le migrazioni. Ciò consente di specificare lo schema del database nel codice C # e di scorrere su e giù la versione del database utilizzando MSBuild.

Attualmente sto usando DbUp e ha funzionato bene.


11

Non hai menzionato dettagli sull'ambiente di destinazione o sui vincoli, quindi potrebbe non essere del tutto applicabile ... ma se stai cercando un modo per tracciare in modo efficace uno schema DB in evoluzione e non sei contrario all'idea di utilizzare Ruby, le migrazioni di ActiveRecord sono perfette per te.

Le migrazioni definiscono programmaticamente le trasformazioni del database usando un Ruby DSL; ogni trasformazione può essere applicata o (di solito) ripristinata, consentendo di passare a una versione diversa dello schema DB in qualsiasi momento. Il file che definisce queste trasformazioni può essere verificato nel controllo di versione come qualsiasi altro pezzo di codice sorgente.

Poiché le migrazioni fanno parte di ActiveRecord , in genere trovano impiego nelle app Rails full-stack; tuttavia, è possibile utilizzare ActiveRecord indipendentemente da Rails con il minimo sforzo. Vedi qui per un trattamento più dettagliato dell'uso delle migrazioni di AR al di fuori di Rails.


10

Ogni database dovrebbe essere sotto il controllo del codice sorgente. Ciò che manca è uno strumento per lo script automatico di tutti gli oggetti del database - e "dati di configurazione" - su file, che possono quindi essere aggiunti a qualsiasi sistema di controllo del codice sorgente. Se si utilizza SQL Server, la mia soluzione è qui: http://dbsourcetools.codeplex.com/ . Divertiti. - Nathan.


9

È semplice.

  1. Quando il progetto di base è pronto, è necessario creare uno script di database completo. Questo script è sottoposto a SVN. È la prima versione.

  2. Successivamente tutti gli sviluppatori creano script di modifica (ALTER ..., nuove tabelle, sprocs, ecc.).

  3. Quando è necessaria la versione corrente, è necessario eseguire tutti i nuovi script di modifica.

  4. Quando l'app viene rilasciata in produzione, si torna a 1 (ma ovviamente sarà la versione successiva).

Nant ti aiuterà a eseguire quegli script di modifica. :)

E ricorda. Tutto funziona bene quando c'è disciplina. Ogni volta che si commette la modifica del database, vengono commesse anche le corrispondenti funzioni nel codice.


2
Dopo alcuni anni dico: Usa FluentMigrator (o uno strumento simile per la tua piattaforma).
dariol,

8

Per rendere il dump di un sistema di controllo del codice sorgente un po 'più veloce, puoi vedere quali oggetti sono cambiati dall'ultima volta usando le informazioni sulla versione in sysobjects.

Installazione: creare una tabella in ciascun database che si desidera controllare in modo incrementale per contenere le informazioni sulla versione dall'ultima volta che è stato verificato (vuoto alla prima esecuzione). Cancella questa tabella se desideri ripetere la scansione dell'intera struttura dei dati.

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)
)

Modalità di esecuzione normale: puoi ottenere i risultati da questo sql e generare script sql solo per quelli a cui sei interessato e metterli in un controllo del codice sorgente a tua scelta.

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

Nota: se si utilizza un confronto non standard in uno dei database, sarà necessario sostituirlo /* COLLATE */con il confronto dei database. vale a direCOLLATE Latin1_General_CI_AI


8

Poiché la nostra app deve funzionare su più RDBMS, memorizziamo la definizione del nostro schema nel controllo della versione utilizzando il formato Torque (XML) neutro dal database . Controlliamo anche i dati di riferimento per il nostro database in formato XML come segue (dove "Relazione" è una delle tabelle di riferimento):

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

Quindi utilizziamo strumenti di produzione interna per generare l'aggiornamento dello schema e gli script di aggiornamento dei dati di riferimento necessari per passare dalla versione X del database alla versione X + 1.


8

Se si dispone di un piccolo database e si desidera eseguire la versione dell'intera cosa, questo script batch potrebbe essere di aiuto. Stacca, comprime e controlla un file MDF del database MSSQL in Subversion.

Se si desidera principalmente eseguire la versione dello schema e disporre solo di una piccola quantità di dati di riferimento, è possibile utilizzare SubSonic Migrations per gestirlo. Il vantaggio è che puoi migrare facilmente verso l'alto o verso il basso verso qualsiasi versione specifica.


7

Non memorizziamo lo schema del database, memorizziamo le modifiche al database. Ciò che facciamo è archiviare le modifiche dello schema in modo da creare uno script di modifica per qualsiasi versione del database e applicarlo ai database dei nostri clienti. Ho scritto un'app di utilità di database che viene distribuita con la nostra applicazione principale in grado di leggere quello script e sapere quali aggiornamenti devono essere applicati. Ha anche abbastanza intelligenza per aggiornare le viste e le procedure memorizzate secondo necessità.


7

Avevamo la necessità di versioni del nostro database SQL dopo la migrazione a una piattaforma x64 e la nostra vecchia versione ha rotto con la migrazione. Abbiamo scritto un'applicazione C # che utilizzava SQLDMO per mappare tutti gli oggetti SQL in una cartella:

                Radice
                    Nome del server
                       Nome del database
                          Oggetti schema
                             Trigger del database *
                                .ddltrigger.sql
                             funzioni
                                ..function.sql
                             Sicurezza
                                ruoli
                                   Ruoli dell'applicazione
                                      .approle.sql
                                   Ruoli del database
                                      .role.sql
                                schemi *
                                   .schema.sql
                                utenti
                                   .user.sql
                             Conservazione
                                Cataloghi full-text *
                                   .fulltext.sql
                             Procedura di archiviazione
                                ..proc.sql
                             Sinonimi *
                                .synonym.sql
                             tabelle
                                ..table.sql
                                vincoli
                                   ... chkconst.sql
                                   ... defconst.sql
                                indici
                                   ... index.sql
                                chiavi
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                trigger
                                   ... trigger.sql
                             tipi
                                Tipi di dati definiti dall'utente
                                   ..uddt.sql
                                Raccolte di schemi XML *
                                   ..xmlschema.sql
                             Visualizzazioni
                                ..view.sql
                                indici
                                   ... index.sql
                                trigger
                                   ... trigger.sql

L'applicazione quindi confronterebbe la versione appena scritta con la versione memorizzata in SVN e se ci fossero differenze aggiornerebbe SVN. Abbiamo stabilito che l'esecuzione del processo una volta a notte era sufficiente poiché non apportiamo molte modifiche a SQL. Ci consente di tenere traccia delle modifiche a tutti gli oggetti a cui teniamo, inoltre ci consente di ricostruire il nostro schema completo in caso di un problema serio.


Oooh, sarebbe bello renderlo pubblicamente disponibile.
Chris Charabaruk,

7

Ho scritto questa app qualche tempo fa, http://sqlschemasourcectrl.codeplex.com/ che scansionerà i tuoi db SQL MSFT tutte le volte che vuoi e scaricherà automaticamente i tuoi oggetti (tabelle, viste, processi, funzioni, impostazioni sql) in SVN. Funziona come un fascino. Lo uso con Unfuddle (che mi consente di ricevere avvisi sui check-in)


6

La soluzione tipica è scaricare il database secondo necessità e fare il backup di quei file.

A seconda della piattaforma di sviluppo, potrebbero essere disponibili plug-in opensource. Rotolare il proprio codice per farlo è di solito abbastanza banale.

Nota: è possibile eseguire il backup del dump del database anziché metterlo nel controllo versione. I file possono ottenere molto velocemente nel controllo della versione e causare un rallentamento dell'intero sistema di controllo del codice sorgente (al momento sto ricordando una storia horror CVS).


6

Abbiamo appena iniziato a utilizzare Team Foundation Server. Se il tuo database è di medie dimensioni, Visual Studio ha alcune belle integrazioni di progetto con confronto integrato, confronto dei dati, strumenti di refactoring del database, framework di test del database e persino strumenti di generazione dei dati.

Ma quel modello non si adatta molto bene a database di grandi dimensioni o di terze parti (che crittografano gli oggetti). Quindi, ciò che abbiamo fatto è memorizzare solo i nostri oggetti personalizzati. Visual Studio / Team Foundation Server funziona molto bene per questo.

Arch. Capo database TFS blog

Sito MS TFS


6

Concordo con la risposta ESV e per questo motivo ho avviato un po 'di progetto un po' di tempo fa per aiutare a mantenere gli aggiornamenti del database in un file molto semplice che poteva quindi essere mantenuto un codice sorgente lungo. Consente facili aggiornamenti agli sviluppatori, UAT e produzione. Lo strumento funziona su Sql Server e MySql.

Alcune caratteristiche del progetto:

  • Consente modifiche allo schema
  • Consente la popolazione dell'albero dei valori
  • Consente inserimenti di dati di prova separati per es. SVS
  • Consente l'opzione per il rollback (non automatizzato)
  • Mantiene il supporto per SQL server e Mysql
  • Ha la capacità di importare il database esistente nel controllo versione con un semplice comando (solo sql server ... funziona ancora su mysql)

Il codice è ospitato su codice google. Consulta il codice Google per ulteriori informazioni

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


5

Qualche tempo fa ho trovato un modulo VB bas che utilizzava oggetti DMO e VSS per ottenere un intero db copiato e inserito in VSS. L'ho trasformato in uno script VB e l'ho pubblicato qui . Potresti facilmente eliminare le chiamate VSS e utilizzare le cose DMO per generare tutti gli script, quindi chiamare SVN dallo stesso file batch che chiama VBScript per registrarle?

Dave J


5

Sto anche usando una versione nel database memorizzata tramite la famiglia di procedure estesa delle proprietà del database. La mia applicazione ha degli script per ogni passaggio della versione (es. Passare da 1.1 a 1.2). Una volta distribuito, esamina la versione corrente e quindi esegue gli script uno alla volta fino a raggiungere l'ultima versione dell'app. Non esiste uno script con la versione 'finale' diretta, anche la distribuzione su un DB pulito esegue la distribuzione tramite una serie di passaggi di aggiornamento.

Quello che mi piace aggiungere è che ho visto due giorni fa una presentazione nel campus MS sulla nuova e imminente edizione di VS DB. La presentazione si è concentrata specificamente su questo argomento e sono rimasto senza parole. Dovresti assolutamente provarlo, le nuove strutture sono focalizzate sul mantenimento della definizione dello schema negli script T-SQL (CREATEs), un motore delta di runtime per confrontare lo schema di distribuzione con lo schema definito e fare gli ALTER delta e l'integrazione con l'integrazione del codice sorgente, fino a e inclusa l'integrazione continua di MSBUILD per drop di build automatizzati. Il drop conterrà un nuovo tipo di file, i file .dbschema, che possono essere portati nel sito di distribuzione e uno strumento da riga di comando può eseguire i "delta" effettivi ed eseguire la distribuzione. Ho un post sul blog su questo argomento con collegamenti ai download di VSDE, dovresti verificarli:http://rusanu.com/2009/05/15/version-control-and-your-database/


5

È una domanda molto antica, tuttavia molti stanno provando a risolverlo anche adesso. Tutto quello che devono fare è fare ricerche sui progetti di database di Visual Studio. Senza questo, qualsiasi sviluppo di database sembra molto debole. Dall'organizzazione del codice alla distribuzione al controllo delle versioni, semplifica tutto.


3

Nella mia esperienza la soluzione è duplice:

  1. È necessario gestire le modifiche al database di sviluppo eseguite da più sviluppatori durante lo sviluppo.

  2. È necessario gestire gli aggiornamenti del database nei siti dei clienti.

Per gestire il n. 1 avrai bisogno di un potente strumento di diff / merge di database. Lo strumento migliore dovrebbe essere in grado di eseguire l'unione automatica il più possibile consentendo al contempo di risolvere manualmente i conflitti non gestiti.

Lo strumento perfetto dovrebbe gestire le operazioni di unione utilizzando un algoritmo di unione a 3 vie che tiene conto delle modifiche apportate nel database THEIRS e nel database MINE, relativamente al database BASE.

Ho scritto uno strumento commerciale che fornisce il supporto di unione manuale per i database SQLite e attualmente sto aggiungendo il supporto per l'algoritmo di unione a 3 vie per SQLite. Dai un'occhiata a http://www.sqlitecompare.com

Per gestire il n. 2 è necessario disporre di un framework di aggiornamento.

L'idea di base è quella di sviluppare un framework di aggiornamento automatico che sappia aggiornare da uno schema SQL esistente allo schema SQL più recente e sia in grado di creare un percorso di aggiornamento per ogni installazione di DB esistente.

Consulta il mio articolo sull'argomento in http://www.codeproject.com/KB/database/sqlite_upgrade.aspx per avere un'idea generale di cosa sto parlando.

In bocca al lupo

Liron Levi


3

Dai un'occhiata a DBGhost http://www.innovartis.co.uk/ . Ho usato in modo automatizzato per 2 anni e funziona benissimo. Permette che le nostre build DB avvengano in modo molto simile a una build Java o C, ad eccezione del database. Sai cosa intendo.


2

Suggerirei di utilizzare strumenti di confronto per improvvisare un sistema di controllo della versione per il tuo database. Una buona alternativa sono xSQL Schema Compare e xSQL Data Compare .

Ora, se il tuo obiettivo è avere solo lo schema del database sotto il controllo della versione, puoi semplicemente usare xSQL Schema Compare per generare snapshot xSQL dello schema e aggiungere questi file nel controllo della versione. Pertanto, per ripristinare o aggiornare a una versione specifica basta confrontare la versione corrente del database con lo snapshot per la versione di destinazione.

Purtroppo, se si desidera avere anche i dati sotto il controllo della versione, è possibile utilizzare xSQL Data Compare per generare script di modifica per il proprio database e aggiungere i file .sql nel controllo della versione. È quindi possibile eseguire questi script per ripristinare / aggiornare la versione desiderata. Tenere presente che per la funzionalità di "ripristino" è necessario generare script di modifica che, quando eseguiti, renderanno la Versione 3 uguale alla Versione 2 e per la funzionalità di "aggiornamento", è necessario generare script di modifica che facciano il contrario.

Infine, con alcune competenze di programmazione batch di base è possibile automatizzare l'intero processo utilizzando le versioni da riga di comando di xSQL Schema Compare e xSQL Data Compare

Disclaimer: sono affiliato a xSQL.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.