[pugMI] [OT] Database legacy

[Matteo Vaccari]

Se vuoi fare un sistema di sincronizzazione fra i due database, l'unico
consiglio che ti do e' di scrivere un job che faccia un controllo di
quadratura fra i due DB.  Cioe' ad esempio, se ho transazioni per 10.000
euro da una parte, ce ne devono essere altrettanti dall'altra.  Lo esegui
ogni tot ore per verificare che la sincronizzazione non faccia errori.  Ho
imparato per esperienza che anche se ti senti sicuro di non averne bisogno,
e' meglio farlo :)

2014-09-10 10:46 GMT+02:00 Gaetano Giunta <giunta.gaetano a gmail.com>:

> Simone Fumagalli wrote:
>
>> Ciao a tutti.
>>
>> Quello di inserire un layer software per far vedere alla mia
>> applicazione un modello di dati differente da quello reale è una cosa
>> che avevo valutato ma che non mi aiuta a risolve il problema. Tra X
>> mesi mi troverei con un'applicazione nuova che usa un modello di dati
>> ben organizzato ma che non corrisponde allo schema del DB.
>>
>> Io invece voglio apportare modifiche, anche sostanziali, allo schema
>> attuale perchè si manifestano sempre più problemi di performance e di
>> evoluzione.
>>
>> Quello che mi servirebbe è una sorta di "replica dei dati del DB con
>> cambio di schema". Un processo costante di ETL dal vecchio al nuovo
>> DB. In questo modo avrei il nuovo applicativo che legge dal nuovo
>> modello, che a tendere diventerebbe il "master", sul quale posso
>> sviluppare i nuovi applicativi o portare quelli vecchi senza
>> compromettere il funzionamento degli script legacy.
>>
>> Sto cercando se esitono prodotti che possano aiutarmi ma sto anche
>> valutando se riesco a gestire la cosa con trigger e/o stored
>> procedure.
>>
>
> Ovviamente un db che supporta trigger e stored procedures aiuta
> notevolmente nel tuo caso.
>
> Di fatto se hai le SP a disposizione io suggerirei di basare
> esclusivamente su accesso  a SP (e non a tabelle) l'API della nuova
> applicazione. Questo ti permette di giocare con le modifiche allo schema
> senza avere continuo refactoring lato applicazione. Ovviamente se il
> linguaggio di programmazione del db ti risulta accettabile (lo devi
> imparare da zero? riesci a gestire il codice con versioning? vuoi scrivere
> tests per quel codice?).
>
> Utilizzare delle viste e' un altro metodo utile.
> P.e.:
> - ferma le app 'legacy'
> - rinomina le vecchie tabelle
> - aggiungi le colonne
> - crea delle viste su tali tabelle con i nomi preesistenti e le colonne
> preesistenti
> - fai ripartire le app legacy
> - allo stesso modo utilizza delle viste per la nuova app, di modo che sia
> anch'essa slegata dallo schema fisico
>
> Anche le FK aiutano: garantiscono che le tue modifiche non distruggono
> l'integrita' dei dati nello schema originale. Lo schema attuale le
> implementa?
>
> Se vuoi creare un secondo schema che sia una replica di quello legacy
> basandoti su triggers che copiano i dati in tempo reale, google dovrebbe
> bastare per trovare vari esempi.
> Il problema pero' si fa complesso nel momento in cui la tua applicazione
> ha bisogno non solo di leggere i dati dallo schema modificato ma anche di
> modificarli. Quale dei 2 schemi consideri "master"? E come risolvi i
> conflitti?
>
> Ciao
> Gaetano
>
> ps: anche toad (oracle) e toad-for-mysql hanno un ottimo supporto per
> l'analisi delle differenze tra schemi. Non sono propriamente gratis ne
> oss...
>
>
>
>> Ciao e grazie a tutti
>>
>> --
>> Simone
>> _______________________________________________
>> Milano mailing list
>> Milano a ml.grusp.org
>> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
>>
>>
> _______________________________________________
> Milano mailing list
> Milano a ml.grusp.org
> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20140910/31665534/attachment.htm>