Controllo del codice sorgente del database vs.script di modifica dello schema

Question

Costruire e mantenere un database che viene poi distribuito/sviluppato ulteriormente da molti sviluppatori è qualcosa che accade continuamente nello sviluppo del software.Creiamo uno script di compilazione e manteniamo ulteriori script di aggiornamento che vengono applicati man mano che il database cresce nel tempo.Esistono molti modi per gestirlo, dagli aggiornamenti manuali alle app della console/script di compilazione che aiutano ad automatizzare questi processi.

Qualcuno che ha creato/gestito questi processi è passato a una soluzione di controllo del codice sorgente per la gestione dello schema del database?Se sì, quale hanno ritenuto che fosse la soluzione migliore?Ci sono delle trappole che dovrebbero essere evitate?

Red Gate sembra essere un grande attore nel mondo MSSQL e il loro controllo del codice sorgente DB sembra molto interessante:http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm

Anche se non sembra che sostituisca il processo di gestione dei dati* (predefinito), quindi sostituisce solo metà del processo di gestione delle modifiche dal mio punto di vista.

(quando parlo di dati, intendo valori di ricerca e cose del genere, dati che devono essere distribuiti per impostazione predefinita o in uno scenario DR)

Lavoriamo in un ambiente .Net/MSSQL, ma sono sicuro che la premessa è la stessa per tutti i linguaggi.

Answer 1

Domande simili

Una o più di queste domande esistenti potrebbero essere utili:

• Il modo migliore per gestire le modifiche al database
• Monitoraggio delle modifiche al database MySQL
• Procedure consigliate per il flusso di lavoro di modifica del database SQL Server
• Verificare le modifiche al database (controllo della versione)
• Trasferimento delle modifiche da un DB di sviluppo a un DB di produzione
• tenere traccia delle modifiche apportate alla struttura del database

Oppure una ricerca per Modifica della banca dati

Answer 2

Mi occupo di un data warehouse sviluppato internamente dalla banca dove lavoro.Ciò richiede un aggiornamento costante e abbiamo un team di 2-4 sviluppatori che ci lavora.

Siamo fortunati perché esiste una sola istanza del nostro "prodotto", quindi non dobbiamo provvedere alla distribuzione su più istanze che potrebbero trovarsi in versioni diverse.

Manteniamo un file di script di creazione per ogni oggetto (tabella, vista, indice, procedura memorizzata, trigger) nel database.

Evitiamo l'uso di ALTER TABLE quando possibile, preferendo rinominare una tabella, crearne una nuova e migrare i dati.Ciò significa che non dobbiamo esaminare la storia di ALTER script: possiamo sempre vedere la versione aggiornata di ogni tabella guardando il suo script di creazione.La migrazione viene eseguita da uno script di migrazione separato: questo può essere parzialmente generato automaticamente.

Ogni volta che eseguiamo un rilascio, abbiamo uno script che esegue gli script di creazione/migrazione nell'ordine appropriato.

PER TUA INFORMAZIONE:Usiamo Visual SourceSafe (che schifo!) per il controllo del codice sorgente.

Answer 3

Stavo cercando uno strumento di controllo del codice sorgente di SQL Server e mi sono imbattuto in molte versioni premium che svolgono il lavoro utilizzando SQL Server Management Studio come plug-in.

LiquiBase è gratuito ma non sono mai riuscito a farlo funzionare per le mie esigenze.

Esiste però un altro prodotto gratuito disponibile sul mercato che funziona parallelamente a SSMS e crea script di oggetti e dati in file flat.

Questi oggetti possono quindi essere inseriti in una nuova istanza di SQL Server che ricreerà quindi gli oggetti del database.

Vedere gitSQL

Answer 4

Forse stai chiedendo LiquiBase?