[pugMI] [OT] Database legacy

[Gaetano Giunta]

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
>