<div dir="ltr">Ciao Simone, forse dovresti dare più dettagli sullo scenario, in modo da poter ricevere suggerimenti più specifici relativamente alla tua situazione, dettagli tipo: quali/quanti applicativi hanno accesso a questo database? come avviene il popolamento (es input utente, script automatizzato, web service, api...)? quanti punti di rigidità esistono, ovvero parti di software coinvolti che non possono essere modificati (ad esempio, sul db scrive o legge un applicativo terze parti)... Da quel che dici nella tua ultima mail sembri far trasparire che nello scenario è presente un qualche sistema di popolamento su cui non puoi intervenire, e quindi il popolamento deve sempre avvenire sul vecchio schema, mentre tu vorresti poter interagire su un nuovo schema più performante per le query. A questo punto potresti creare uno script periodico di "aggiornamento" da un db all'altro, il che ti darebbe il risultato che cerchi senza dover correre il rischio di apportare modifiche potenzialmente rovinose per una parte del tuo sistema.</div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 10 settembre 2014 09:44, Simone Fumagalli <span dir="ltr"><<a href="mailto:simone@iliveinperego.com" target="_blank">simone@iliveinperego.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ciao a tutti.<br>
<br>
Quello di inserire un layer software per far vedere alla mia<br>
applicazione un modello di dati differente da quello reale è una cosa<br>
che avevo valutato ma che non mi aiuta a risolve il problema. Tra X<br>
mesi mi troverei con un'applicazione nuova che usa un modello di dati<br>
ben organizzato ma che non corrisponde allo schema del DB.<br>
<br>
Io invece voglio apportare modifiche, anche sostanziali, allo schema<br>
attuale perchè si manifestano sempre più problemi di performance e di<br>
evoluzione.<br>
<br>
Quello che mi servirebbe è una sorta di "replica dei dati del DB con<br>
cambio di schema". Un processo costante di ETL dal vecchio al nuovo<br>
DB. In questo modo avrei il nuovo applicativo che legge dal nuovo<br>
modello, che a tendere diventerebbe il "master", sul quale posso<br>
sviluppare i nuovi applicativi o portare quelli vecchi senza<br>
compromettere il funzionamento degli script legacy.<br>
<br>
Sto cercando se esitono prodotti che possano aiutarmi ma sto anche<br>
valutando se riesco a gestire la cosa con trigger e/o stored<br>
procedure.<br>
<br>
Ciao e grazie a tutti<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Simone<br>
_______________________________________________<br>
Milano mailing list<br>
<a href="mailto:Milano@ml.grusp.org">Milano@ml.grusp.org</a><br>
<a href="http://ml.grusp.org/listinfo.cgi/milano-grusp.org" target="_blank">http://ml.grusp.org/listinfo.cgi/milano-grusp.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Pier Paolo Grassi<br><a href="mailto:pierpaolog@gmail.com" target="_blank">pierpaolog@gmail.com</a><br>
</div>