Controllo delle versioni del database SQL Server

StackOverflow https://stackoverflow.com/questions/173

Domanda

Voglio che i miei database siano sotto il controllo della versione.Qualcuno ha qualche consiglio o articolo consigliato per iniziare?

Ne vorrò sempre avere almeno Alcuni dati presenti (come allume menziona:tipologie di utenti e amministratori).Avrò spesso bisogno anche di un'ampia raccolta di dati di test generati per la misurazione delle prestazioni.

È stato utile?

Soluzione

Martin Fowler ha scritto il mio articolo preferito sull'argomento, http://martinfowler.com/articles/evodb.html.Scelgo di non inserire i dump dello schema sotto il controllo della versione come allume e altri lo suggeriscono perché desidero 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

Una sequenza di script di aggiornamento del database 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 vengano eseguiti una sola volta.Ancora una volta, questi lo sono non dump del database.Piuttosto, ogni script rappresenta il i cambiamenti necessario passare da una versione a quella successiva.Sono lo script che applichi al tuo database di produzione per "aggiornarlo".

Sincronizzazione sandbox per sviluppatori

  1. Uno script per eseguire il backup, disinfettare e ridurre un database di produzione.Eseguilo 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 automatizzati vengono eseguiti su un database corretto ma vuoto, quindi questo consiglio non si adatta perfettamente alle tue esigenze.

Altri suggerimenti

Il prodotto SQL Compare di Red Gate non solo ti consente di eseguire confronti a livello di oggetto e generare script di modifica da esso, ma ti consente anche di esportare gli oggetti del tuo database in una gerarchia di cartelle organizzata per tipo di oggetto, con una creazione di [nomeoggetto].sql script per oggetto in queste directory.La gerarchia dei tipi di oggetto è così:

\Funzioni
\Sicurezza
\Sicurezza uoli
\Sicurezza\Schemi
\Sicurezza\Utenti
\Procedura di archiviazione
abelle

Se scarichi i tuoi script nella stessa directory root dopo aver apportato modifiche, puoi utilizzarlo per aggiornare il tuo repository SVN e mantenere una cronologia di esecuzione di ciascun oggetto individualmente.

Questo è uno dei “problemi difficili” che circondano lo sviluppo.Per quanto ne so non esistono soluzioni perfette.

Se è necessario memorizzare solo la struttura del database e non i dati, è possibile esportare il database come query SQL.(in Gestore aziendale:Fare clic con il tasto destro sul database -> Genera script SQL.Consiglio di impostare "crea un file per oggetto" nella scheda delle opzioni) Puoi quindi inviare questi file di testo a svn e utilizzare le funzioni diff e logging di svn.

L'ho legato insieme a 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 da qualche parte accessibile)

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

Per prima cosa devi scegliere il sistema di controllo della versione più adatto a te:

  • Sistema di controllo versione centralizzato: un sistema standard in cui gli utenti effettuano il check-out/il check-in prima/dopo aver lavorato sui file e i file vengono conservati in un unico 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 qualsiasi server si arresta, allora qualsiasi repository clonato può essere utilizzato per ripristinarlo dopo aver scelto il sistema giusto per le tue esigenze , dovrai configurare il repository che è il nucleo di ogni sistema di controllo della versione tutto ciò che è 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 della versione centrale, una cartella di lavoro, è possibile leggere Questo articolo.Mostra come impostare il controllo del codice sorgente in un ambiente di sviluppo utilizzando:

  • SQL Server Management Studio tramite il provider MSSCCI,

  • Strumenti dati di Visual Studio e SQL Server

  • Uno strumento di terze parti ApexSQL Source Control

Qui a Red Gate offriamo uno strumento, Controllo del codice sorgente SQL, che utilizza la tecnologia SQL Compare per collegare il tuo database a un repository TFS o SVN.Questo strumento si integra in SSMS e ti consente di lavorare come faresti normalmente, tranne che ora ti consente di salvare gli oggetti.

Per un approccio basato sulle migrazioni (più adatto per distribuzioni automatizzate), offriamo Automazione delle modifiche SQL (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 vengono archiviati nel controllo del codice sorgente come istruzioni INSERT.

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

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

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

SqlCompare ha anche un'API decentemente documentata:così 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 archivia una modifica allo schema dalla cartella degli script, viene automaticamente distribuita insieme all'applicazione corrispondente modifica del codice.Ciò aiuta a colmare il divario con gli sviluppatori che dimenticano di propagare le modifiche nel loro database locale fino a un DB di sviluppo condiviso (circa la metà di noi, credo :)).

Un avvertimento è che con una soluzione basata su script o meno, gli strumenti RedGate sono sufficientemente fluidi da rendere facile dimenticare le realtà SQL alla base dell'astrazione.Se rinomini tutte le colonne in una tabella, SqlCompare non ha modo di mappare le vecchie colonne sulle nuove colonne e eliminerà tutti i dati nella tabella.Genererà avvisi ma ho visto persone fare clic oltre.C'è un punto generale che vale la pena sottolineare, penso, che finora è possibile automatizzare solo il controllo delle versioni e l'aggiornamento del DB: le astrazioni sono molto perdenti.

Noi usiamo DBGhost per gestire il nostro database SQL.Quindi inserisci i tuoi 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 comunque farlo, se ad esempio vuoi cambiare il tipo di dati di una colonna e devi convertire i dati).

Con VS 2010, utilizzare il progetto Database.

  1. Crea il tuo database
  2. Apportare modifiche agli script o direttamente sul server DB
  3. Sincronizzare utilizzando dati> Schema confronta

Costituisce una soluzione perfetta per il controllo delle versioni dei DB e rende la sincronizzazione dei DB un gioco da ragazzi.

È un buon approccio salvare gli script del database nel controllo della versione con script di modifica in modo da poter aggiornare qualsiasi database di cui disponi.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 svolgere lavoro manuale.

Penso che sia importante avere un database separato per ogni sviluppatore e non utilizzare 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 disporre di mezzi per gestire i metadati del database, che indichino quali database si trovano in quale stato di sviluppo e quali tabelle contengono dati controllabili dalla versione e così via.

Potresti anche considerare una soluzione di migrazione.Questi ti consentono di specificare lo schema del tuo database nel codice C# e di eseguire il roll up e il down della versione del database utilizzando MSBuild.

Attualmente sto utilizzando DbUp, e ha funzionato bene.

Non hai menzionato alcuna specifica relativa all'ambiente di destinazione o ai vincoli, quindi questo potrebbe non essere del tutto applicabile...ma se stai cercando un modo per tenere traccia in modo efficace di uno schema DB in evoluzione e non sei contrario all'idea di utilizzare Ruby, le migrazioni di ActiveRecord fanno al caso tuo.

Le migrazioni definiscono in modo programmatico le trasformazioni del database utilizzando un Ruby DSL;ogni trasformazione può essere applicata o (solitamente) ripristinata, consentendoti di passare a una versione diversa del tuo schema DB in qualsiasi momento.Il file che definisce queste trasformazioni può essere archiviato nel controllo versione come qualsiasi altra parte di codice sorgente.

Perché le migrazioni ne fanno parte Registrazione attiva, in genere trovano utilizzo nelle app Rails full-stack;tuttavia, puoi utilizzare ActiveRecord indipendentemente da Rails con il minimo sforzo.Vedere Qui per una trattazione più dettagliata dell'utilizzo delle migrazioni di AR al di fuori di Rails.

Ogni database dovrebbe essere sotto il controllo del codice sorgente.Ciò che manca è uno strumento per scrivere automaticamente tutti gli oggetti del database - e i "dati di configurazione" - in un file, che poi può essere aggiunto a qualsiasi sistema di controllo del codice sorgente.Se stai utilizzando SQL Server, la mia soluzione è qui: http://dbsourcetools.codeplex.com/ .Divertiti.- Nathan.

È semplice.

  1. Quando il progetto di base è pronto, è necessario creare lo script del database completo.Questo script è impegnato in SVN.È la prima versione.

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

  3. Quando hai bisogno della versione corrente, dovresti eseguire tutti i nuovi script di modifica.

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

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

E ricorda.Tutto funziona bene quando c’è disciplina.Ogni volta che viene eseguita la modifica del database, vengono eseguite anche le funzioni corrispondenti nel codice.

Se disponi di un database di piccole dimensioni e desideri creare la versione dell'intero elemento, questo script batch potrebbe aiutare.Scollega, comprime e controlla un file MDF del database MSSQL in Subversion.

Se desideri principalmente modificare la versione del tuo schema e avere solo una piccola quantità di dati di riferimento, puoi eventualmente utilizzare Migrazioni subsoniche per gestirlo.Il vantaggio è che puoi facilmente migrare verso l'alto o verso il basso a qualsiasi versione specifica.

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

Impostare: Crea una tabella in ogni database che desideri controllare in modo incrementale per conservare le informazioni sulla versione dall'ultima volta che l'hai controllata (vuota alla prima esecuzione).Cancella questa tabella se desideri eseguire nuovamente 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 funzionamento normale: Puoi prendere i risultati da questo SQL e generare script SQL solo per quelli che ti interessano e inserirli in un controllo del codice sorgente di 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 utilizzi un confronto non standard in uno qualsiasi dei tuoi database, dovrai sostituirlo /* COLLATE */ con le regole di confronto del database.cioè. COLLATE Latin1_General_CI_AI

Poiché la nostra app deve funzionare su più RDBMS, memorizziamo la nostra definizione di schema nel controllo della versione utilizzando il database neutrale Coppia formato (XML).Inoltre controlliamo la versione dei 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.

Utilizziamo quindi strumenti sviluppati internamente per generare gli script di aggiornamento dello schema e di aggiornamento dei dati di riferimento necessari per passare dalla versione X del database alla versione X + 1.

Non memorizziamo lo schema del database, memorizziamo le modifiche al database.Ciò che facciamo è archiviare le modifiche allo 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à del database che viene distribuita con la nostra applicazione principale in grado di leggere lo script e sapere quali aggiornamenti devono essere applicati.Dispone inoltre di funzionalità intelligenti sufficienti per aggiornare visualizzazioni e procedure memorizzate secondo necessità.

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

                Root
                    ServerName
                       DatabaseName
                          Schema Objects
                             Database Triggers*
                                .ddltrigger.sql
                             Functions
                                ..function.sql
                             Security
                                Roles
                                   Application Roles
                                      .approle.sql
                                   Database Roles
                                      .role.sql
                                Schemas*
                                   .schema.sql
                                Users
                                   .user.sql
                             Storage
                                Full Text Catalogs*
                                   .fulltext.sql
                             Stored Procedures
                                ..proc.sql
                             Synonyms*
                                .synonym.sql
                             Tables
                                ..table.sql
                                Constraints
                                   ...chkconst.sql
                                   ...defconst.sql
                                Indexes
                                   ...index.sql
                                Keys
                                   ...fkey.sql
                                   ...pkey.sql
                                   ...ukey.sql
                                Triggers
                                   ...trigger.sql
                             Types
                                User-defined Data Types
                                   ..uddt.sql
                                XML Schema Collections*
                                   ..xmlschema.sql
                             Views
                                ..view.sql
                                Indexes
                                   ...index.sql
                                Triggers
                                   ...trigger.sql

L'applicazione confronterebbe quindi la versione appena scritta con la versione archiviata in SVN e, in caso di differenze, aggiornerebbe SVN.Abbiamo stabilito che eseguire il processo una volta a notte era sufficiente poiché non apportiamo molte modifiche a SQL.Ci consente di tenere traccia delle modifiche apportate a tutti gli oggetti che ci interessano e inoltre ci consente di ricostruire il nostro schema completo in caso di problemi seri.

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

La soluzione tipica è scaricare il database secondo necessità ed eseguire il backup di tali file.

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

Nota:Potresti voler eseguire il backup del dump del database invece di inserirlo nel controllo della versione.I file possono diventare molto veloci nel controllo della versione e rallentare l'intero sistema di controllo del codice sorgente (sto ricordando una storia horror di CVS in questo momento).

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

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

Capo del database TFS arch.blog

Sito MS TFS

Sono d'accordo con la risposta ESV e proprio per questo motivo ho avviato un piccolo progetto qualche tempo fa per aiutare a mantenere gli aggiornamenti del database in un file molto semplice che potrebbe quindi essere mantenuto con un codice sorgente lungo.Consente facili aggiornamenti agli sviluppatori, all'UAT e alla produzione.Lo strumento funziona solo su SQL Server e MySql.

Alcune caratteristiche del progetto:

  • Consente modifiche allo schema
  • Consente il popolamento dell'albero dei valori
  • Consente inserimenti separati di dati di test per es.UAT
  • Consente l'opzione per il rollback (non automatizzato)
  • Mantiene il supporto per SQL Server e Mysql
  • Ha la possibilità di importare il database esistente nel controllo della versione con un semplice comando (solo SQL Server...sto ancora lavorando su MySQL)

Il codice è ospitato su Google Code.Per ulteriori informazioni, controlla il codice Google

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

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

DaveJ

Sto anche utilizzando una versione nel database archiviata tramite la famiglia di procedure delle proprietà estese del database.La mia applicazione dispone di script per ogni passaggio della versione (ad es.passare da 1.1 a 1.2).Una volta distribuito, esamina la versione corrente e quindi esegue gli script uno per uno fino a raggiungere l'ultima versione dell'app.Non esiste uno script che abbia la versione "finale" diretta, anche la distribuzione su un DB pulito esegue la distribuzione tramite una serie di passaggi di aggiornamento.

Ora quello che mi piace aggiungere è che ho visto due giorni fa una presentazione nel campus MS sulla nuova e prossima edizione di VS DB.La presentazione era incentrata specificamente su questo argomento e sono rimasto sbalordito.Dovresti assolutamente provarlo, le nuove funzionalità sono focalizzate sul mantenimento della definizione dello schema negli script T-SQL (CREATE), un motore delta runtime per confrontare lo schema di distribuzione con lo schema definito e sull'esecuzione degli ALTER delta e sull'integrazione con l'integrazione del codice sorgente, fino a e inclusa l'integrazione continua di MSBUILD per i rilasci di build automatizzati.Il rilascio 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 VSDE, dovresti controllarli: http://rusanu.com/2009/05/15/version-control-and-your-database/

È una questione molto vecchia, tuttavia molti stanno cercando di risolverla 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.

Secondo la mia esperienza la soluzione è duplice:

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

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

Per gestire il punto 1 avrai bisogno di un potente strumento di confronto/unione del database.Lo strumento migliore dovrebbe essere in grado di eseguire il più possibile l'unione automatica, consentendo al tempo stesso 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 tenga conto delle modifiche apportate nel database THEIRS e nel database MINE, rispetto al database BASE.

Ho scritto uno strumento commerciale che fornisce il supporto dell'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 punto 2 sarà necessario disporre di un framework di aggiornamento.

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

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

Buona fortuna

Liron Levi

Dai un'occhiata a DBGhost http://www.innovartis.co.uk/.Lo utilizzo in modo automatizzato ormai da 2 anni e funziona benissimo.Consente alle nostre build di DB di avvenire in modo molto simile a una build Java o C, ad eccezione del database.Sai cosa voglio dire.

Suggerirei di utilizzare strumenti di confronto per improvvisare un sistema di controllo della versione per il tuo database.Una buona alternativa sono Confronto di schemi xSQL E Confronto dati xSQL.

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

Purtroppo, se vuoi avere anche i dati sotto il controllo della versione, puoi utilizzare xSQL Data Compare per generare script di modifica per il tuo database e aggiungere i file .sql nel tuo controllo della versione.Potresti quindi eseguire questi script per ripristinare/aggiornare qualsiasi versione desideri.Tieni presente che per la funzionalità "ripristina" devi generare script di modifica che, una volta eseguiti, renderanno la versione 3 uguale alla versione 2 e per la funzionalità "aggiornamento", devi generare script di modifica che facciano il contrario.

Infine, con alcune competenze di base di programmazione batch è 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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top