Migrazione dello schema: SQL Server Data Tools vs Liquibase e Flyway


11

Potrebbe sembrare una domanda stupida, ma ho cercato soluzioni open source per la migrazione degli schemi, vale a dire Liquibase e Flyway.

Tuttavia, il mio capo mi ha detto che SQL Server Data Tools (SSDT) ​​svolge lo stesso lavoro. Non sono sicuro di essere d'accordo, ma riesco a trovare molto poco su Internet che lo confronta direttamente con Liquibase e / o Flyway.

Il mio punto di vista è che SSDT è uno strumento di sviluppo, modellazione e progettazione di dati per SQL Server e supporta anche il confronto di schemi (e la generazione di script relativi) e il controllo del codice sorgente. Affronta un problema diverso, sebbene ci possano essere alcune sovrapposizioni con Liquibase / Flyway in alcuni aspetti della migrazione dello schema. Ma come strumento di migrazione dello schema complessivo, Liquibase e Flyway sono strumenti completamente dedicati, mentre SSDT è più per la progettazione e lo sviluppo di un database.

Qualsiasi opinione sarebbe molto apprezzata anche solo per dire che non c'è paragone e SSDT non è affatto uno strumento di migrazione dello schema.

Risposte:


17

SSDT è paragonabile a Liquibase / Flyway in quanto fa quello che fanno ma adottando un approccio diverso. Con SSDT hai l'ambiente di sviluppo in modo da ottenere cose come andare alla definizione, trovare riferimenti e intelli-sense, nonché la possibilità di compilare un progetto in un dacpac e quindi distribuire quel dacpac in un database.

Il modo SSDT (e il modo di confronto sql di redgate) per eseguire un diluvio è dichiarare ciò che si desidera, quindi se si desidera modificare una tabella simile a:

create table a(id int)

a un tavolo che assomiglia a:

create table a(id int, another_column varchar(12))

con SSDT basta cambiare la definizione della tabella con la seconda e lasciare che SSDT si preoccupi di come aggiornarla (può fare una tabella alterata, aggiungere una colonna o cambiare l'ordine della colonna, quindi sarà necessario ricostruire la tabella ecc.).

Con Liquibase (DbUp, ReadyRoll, metodi manuali ecc.) Ciò che fai è in questo caso scrivere la tabella alter e assicurarti di eseguire gli script nell'ordine corretto, considera questo scenario:

  1. Rilascio 1: crea la colonna ciao sulla tabella
  2. Rilascio 2: rinomina la colonna hello in joe_blogs
  3. Rilascio 3: rinomina la colonna joe_blogs in Hello
  4. Versione 4: crea una colonna joe_blogs

Se manca una delle versioni, nessuna delle successive può continuare.

Vantaggi degli script di aggiornamento (Liquibase, DbUp, ecc.):

  • Hai il controllo completo sugli script
  • DBA / sviluppatori sono abituati a questo

Vantaggi del confronto / unione (SSDT, Redgate SQL Compare):

  • Non è necessario scrivere script di aggiornamento
  • È facile arrivare a qualsiasi versione specifica basta confrontare e unire quella versione

Svantaggi degli script di aggiornamento:

  • Deve essere eseguito in ordine
  • Non fare errori sugli umani
  • Può essere lento soprattutto se hai molti cambiamenti
  • A meno che il tuo team non disponga di database molto disciplinati in ambienti diversi (sviluppo, test, stadiazione, prod, ecc.) Spesso non sono sincronizzati rendendo non validi i test
  • Il downgrade di una versione significa scrivere il contrario di tutti gli script che hai già scritto

Svantaggi dell'utilizzo di confronta / unisci:

  • Gli strumenti non sono affidabili al 100%, forse ingiustamente
  • SSDT richiede un progetto funzionante, molti database hanno codice che in realtà non viene compilato o eseguito (pensa a tabelle scartate ma non a procedure ecc.), L'ho visto in circa 8/10 database che ho ereditato :)
  • Molti sviluppatori / amministratori di database sono restii a rinunciare allo sviluppo in SSMS / blocco note

Personalmente penso davvero che SSDT sia un ambiente di sviluppo professionale e ciò significa che posso concentrarmi sulla scrittura di codice e test utili piuttosto che sulla scrittura di script di aggiornamento che sono di per sé solo un mezzo per raggiungere un fine.

Hai chiesto opinioni quindi eccoti :)

Ed


1
SSDT funziona con nient'altro che SQL Server? ad es. Postgres?
a_horse_with_no_name

3
Nessun "strumento di dati del server SQL" :)
Ed Elliott,

1
Perchè no? Il pacchetto SSIS può trasferire principalmente tutte le fonti ODBC
a_vlad

A meno che non abbia frainteso, penso che stiamo parlando della gestione dello schema del database piuttosto che della creazione di pacchetti ssis? Felice di essere corretto :)
Ed Elliott,

1
SSIS ha lo scopo di spostare i dati e come tale supporta le connessioni a una grande varietà di sistemi. SSDT è destinato allo sviluppo e alla manutenzione di progetti di database di SQL Server. Ha un processo di compilazione che controlla la versione di SQL Server di destinazione per la compatibilità degli script e controlla tutti i riferimenti, i proc, ecc. Per la sintassi T-SQL.
Dave,

2

Ricarica solo la risposta di previsione.

La più grande differenza descritta sul sito Flyway in posizione centrale:

Risolve solo un problema e risolve bene. Flyway migra il tuo database, quindi non devi più preoccupartene.

Visual Studio + SSDT + SSIS = Strumento ETL a piena potenza, con un solo inconveniente reale: funziona solo con Windows Ha bisogno di Windows + SQL Server per eseguire i pacchetti, ma funziona con quasi tutte le fonti.

Per il trasferimento / migrazione dei dati: molti prodotti sul mercato. Commerciale, Open Source, Community / Express ed ecc

Per il codice di migrazione - non tutto è così buono. Anche se il software promette "convertire trigger, procedure e funzioni senza problemi", in effetti - solo la maggior parte della migrazione del codice - manuale.


2

Ho lavorato con entrambi gli strumenti di dati del server SQL e flyway. Usando SSDT, ottengo i seguenti vantaggi:

  1. Posso compilare il progetto del database .. il che significa che non c'è paura di rilasciare una colonna a cui fa riferimento una vista, una funzione o processi memorizzati. Questa è una grande caratteristica, perché in passato abbiamo scoperto di mancare solo dopo l'uscita
  2. Dopo la compilazione corretta, SSDT genera ciò che è noto come "DACPAC". Pensa a questo un msi con una versione.

  3. Un dato dacpac, con la versione 5, può essere applicato a un database su Dacpac versione 1,2,3,4 o 6,7,8 ecc. Se applicato a 1-4, il database verrà aggiornato. Se applicato a 6,7 ​​ecc., Il DB verrà declassato / ripristinato. Ci saranno avvisi, se ci sarà una perdita di dati, che può essere soppressa. Quindi, abbiamo una grande funzionalità di rollback, che non è disponibile con altri strumenti come flyway ecc. Con flyway, è necessario fornire un nuovo set di script per il rollback.

  4. DACPAC applica tutte le modifiche in una transazione; ciò significa che se vengono apportate 5 modifiche alla tabella nell'aggiornamento e una di esse fallisce, viene eseguito il rollback dell'intera transazione. Flyway supporta anche questo, ma per ogni file.

Tuttavia, SSDT e DACPAC sono specifici di Microsoft SQL Server; flyway può essere utilizzato per una varietà di database.

Quindi, in sostanza, se stai usando solo SQL Server, dovrebbe essere una decisione abbastanza semplice andare con SSDT e DACPAC.

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.