Newsgroup: it.comp.dotnet
Titolo: Gestire aggiornamenti DB

Salve a tutti,
utilizzo 
VB.NET
 e come database Firebird.
 
Ho un'applicazione che richiede "continui" aggiornamenti di versione. Nuove
tabelle, nuovi campi ecc.
 
Fin'ora viene gestito con dei files di script SQL lanciati a mano da noi
sul DB del cliente, ma questo mi può andar bene fino a quando siamo in
test, vorrei poi automatizzare la procedura, in modo che il programma in
automatico porta i database alla versione di lavoro.
 
Così ad occhio avevo pensato a usare un XML con scritto tipo
VERISIONE=1.00
COMANDOSQL=ALTER TABLE PIPPO ADD CAMPO INTEGER;
 
VERISIONE=1.01
COMANDOSQL=ALTER TABLE PIPPO ADD CAMPO2 INTEGER;
 
ecc.
 
In questo modo la procedura di aggiornamento può leggere questo file, vede
a quale versione è il database e portarlo fino all'ultima.
Non ho però grande esperienza con l'uso di XML.
 
Fino ad ora, su procedure VB6 una cosa simile è stata fatta nel codice di
un programma di aggiornamento, che fa un SELECT CASE VersioneDB. Questo
implica però di mandare il programma ricompilato ogni volta, e soprattutto
non mi permette di gestire tabelle diverse per clienti diversi.
 
Qualche consiglio?
Grazie

 Grazie
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 Qualche consiglio?
 
In generale, l'aspetto tecnico si rivela spesso abbastanza semplice, il 
problema principale e' la complessita' intrinsica di avere troppe versioni 
e/o troppi branch da gestire, il che implica parecchio book-keeping in ogni 
caso, e piu' errori.  In aziende dove trovo questo tipo di situazione spingo 
affiche' tutto il branching venga progressivamente e totalmente eliminato 
(riassorbito, per ogni prodotto, in un unico trunk): per le richieste da 
clienti esistenti si adotta una strategia del tipo che o si tratta di un 
semplice cambiamento nella configurazione oppure li si aggiorna direttamente 
all'ultima versione e, al limite, e' quella che si estende (dopo aver 
valutato la richiesta ed averla trasformata in un requirement di interesse 
abbastanza ampio da giustificare la sua introduzione nel prodotto).  I fix 
sono (ovviamente?) gratuiti, e anche quelli si risolvono in un fix del main 
trunk seguito da un upgrade di tutti gli interessati.  --  Si potrebbe 
obiettare che questi upgrade "gratuiti" sono un'occasione di business persa, 
ma andando a quantificare i costi dell'eccessivo branching ci si rende conto 
che c'e' piuttosto e solo da perdere.
 
Poi in realta' non ho capito se e' esattamente quella la tua situazione 
(eccessivo branching), ma se non lo e' mi viene piuttosto in mente che 
allora e' il sistema in questione a mancare di un sufficiente livello di 
astrazione...
 
-LV
 
 

 
http://stackoverflow.com/questions/3437346/net-database-migration-tool
 
 
Ho guardato velocemente ma mi sembrano strettamente legati al DB, e non ho
visto nominato Firebird.
Comunque ci guardo con pi� calma.

 astrazione...
 
Allora per i programmi VB6 abbiamo adottato una tecnica che ogni cliente ha
la stessa versione di DB identica ad un altro. La tabella che usa solo un
cliente se la ritrovano tutti. Poi tutto � bloccato a livello di menu,
maschere ecc. (e decide di IF di personalizzazione :\)
 
Questa situazione mi permette di non avere versioni differenti, ed
eseguibili/DB unici.
 
Non vorrei per� precludermi la possibilit� di avere branch, per alcuni
software che sono altamente personalizzati per ogni cliente, e con poche
installazioni.
 
Impiantando ora le prime procedure .NET volevo creare qualcosa di diverso
da VB6, che ha comunque sempre funzionato con un programma che nel codice
ha:
 
  Select Case VersMIN
      Case 4
        If dbVERS <= VersioneConfronto Then
          AdoCN.Execute "ALTER TABLE PIPPO ADD PROGR INTEGER;"
          AdoCN.Execute "ALTER TABLE PLUTO ADD NOTE VARCHAR(50);"
          AdoCN..Execute "UPDATE VERS SET VERSIONE='4.01';"
        End If
      Case 4.01
	....
 
Cos� per� devo ricompilare ogni volta, ed averne uno per ogni gestionale.
Con un programma generico mi basterebbe distribuire il file/db di elenco
scripts e l'eventuale programma aggiornato che sfrutta tali tabelle.
 
Grazie.

 l'SQL, e utilizzando firebird, vorrei essere sicuro che è "sicuro".
 
Fanno un lavoro che e' concettualmente semplice.  In generale, non sono a 
favore dei tool perche' ritengo che certi strumenti vadano sviluppati 
internamente e gradualmente, di pari passo con l'evolversi del modo di 
lavorare e del livello di auto-consapevolezza.  Poi ovviamente non ha 
neanche senso reinventare la ruota, per cui ad esempio ci penserei due volte 
a trasformare un piccolo sistema interno di controllo versioni in un 
framework di uso generico... ecc. ecc.
 
In bocca al lupo,
 
-LV
 
 

 Comunque ci guardo con più calma.
 
ho trovato anche questo:
http://iainhunter.wordpress.com/2012/08/02/easy-database-migrations-with-c-and-fluentmigrator/
 
