Come ormai è evidente, le nuove esigenze del mercato spingono verso la compliance, al valore e all’agilità del business. Se le applicazioni legacy non soddisfano i nuovi requisiti imposti dal business digitale, devono essere modernizzate per fornire un maggiore valore aziendale; se non possiedono l'agilità per stare al passo con le richieste del business digitale possono rappresentare una responsabilità in termini di costi o rischi.
Le alternative alla modernizzazione che identifica Gartner sono, in generale, quelle descritte di seguito e sono classificate secondo un ordine di difficoltà e rischio – entrambi dal valore più basso al più alto:
- Encapsulate. Sfruttamento ed estensione delle funzionalità dell'applicazione incapsulandone i dati e le funzioni, rendendoli disponibili come servizi tramite API.
- Rehost. Ridistribuzione dei componenti applicativi o dell’applicazione stessa su un'altra infrastruttura (fisica, virtuale o cloud) senza modificarne il codice, le caratteristiche o le funzioni.
- Replatform. Migrazione a una nuova piattaforma di runtime, apportando modifiche minime al codice, ma non alla struttura del codice, alle caratteristiche o alle funzioni.
- Refactor. Ristrutturazione e ottimizzazione del codice sorgente esistente (ma non il suo comportamento esterno) per rimuovere il debito tecnico e migliorare gli attributi non funzionali.
- Rearchitect. Modifica del codice sorgente per spostarlo su una nuova architettura applicativa e sfruttarne nuove e migliori capacità.
- Rebuild. Rivisitazione del disegno architetturale o riscrittura da zero dei componenti applicativi preservandone l'ambito e le specifiche.
- Replace. Eliminazione di tutti i precedenti componenti applicativi e relativa sostituzione, tenendo conto allo stesso tempo di nuove esigenze.
Le "5 R" utilizzate da CAST Highlight
In molti di questi casi, è possibile e consigliabile rivedere o ridisegnare anche il database, che spesso contiene gran parte della logica applicativa sotto forma di stored procedures, funzioni, viste.
Specialmente nel caso che il database non sia ridisegnato completamente, può valere la pena di ottimizzarlo, in termini di Security, Reliability e Performance/Efficiency. Di seguito prenderemo in considerazione alcuni degli aspetti tecnici importanti che devono essere valutati attentamente nel passaggio del database in cloud allo scopo di massimizzare le performance, minimizzare lo spazio necessario e i rischi di SQL injection.
Evitare le query SQL che nessun indice può supportare per gli artefatti con un alto fan-in
Questa metrica recupera gli artefatti con un alto fan-in contenente almeno una query SQL che non usa gli indici di una tabella. Le query SQL che non utilizzano gli indici di tabella sono estremamente pericolose per le prestazioni dell'applicazione. In questi casi, ogni esecuzione della query risulterà in una scansione completa della tabella che richiede molto tempo. Quando gli artefatti hanno un alto fan-in, il rischio è maggiore. La soluzione consiste nell’utilizzare le colonne indicizzate nelle clausole WHERE e HAVING. Se non è possibile, creare un indice secondario per queste colonne.
Evitare le query SQL su tabelle XXL che non sono supportate da alcun indice
Questa metrica recupera gli artefatti contenenti almeno una query SQL su una tabella XXL che non utilizza gli indici della tabella XXL. Le tabelle XXL sono tabelle estremamente grandi che contengono un'enorme quantità di dati. Anche in questo caso valgono le stesse considerazioni fatte per la metrica precedente, relativamente ai tempi di esecuzione e alla scansione completa della tabella
Evitare clausole “exists” indipendenti
La metrica identificherà gli oggetti sql usando "exists" che sono indipendenti (non riferiti all'oggetto genitore). La metrica serve ad isolare problemi di prestazioni e spazio su disco.
Evitare la presenza di tabelle senza chiave primaria
Questa metrica mostra l'elenco di tabelle e viste materializzate senza vincoli di chiave primaria. La presenza di chiavi primarie garantisce l’identificazione univoca e mediante indice di ogni singolo record, evitando, anche in questo caso, la scansione dell’intera tabella.
Nella progettazione di database relazionali, una chiave candidata è solo un identificatore univoco. Successivamente una chiave primaria è una chiave candidata che è stata individuata per identificare in modo univoco ogni riga in una tabella o in una vista materializzata. Una chiave univoca o una chiave primaria comprende una singola colonna o un insieme di colonne. Due righe distinte in una tabella o vista materializzata non possono avere lo stesso valore (o combinazione di valori) in quelle colonne.
A seconda del disegno, una tabella o una vista materializzata possono avere arbitrariamente molte chiavi univoche ma al massimo una chiave primaria.
Nella Parte 2 prenderemo in considerazione aspetti differenti per l’ottimizzazione e razionalizzazione del database
Comments: