Innanzitutto, lasciatemi affermare chiaramente che sono completamente contrario a questo, ho problemi reali con codice inutile, obsoleto, non testato, merdoso, specialmente quando finiscono su un sistema di produzione. Il mio background è in build e release management / devops e ora sto lavorando come consulente tecnico a supporto di un team di sviluppo in outsourcing.
Lo scenario è questo;
Abbiamo un sistema MI che ha pubblicato i dati da circa 200 tabelle di origine in 200 tabelle di destinazione in base a una singola stored procedure "dinamica" che genera ed esegue le istruzioni MERGE (per ogni tabella). Il contenuto di queste istruzioni MERGE è guidato da varie tabelle di configurazione (da origine a destinazione a livello di colonna).
Anche se non sono un fan completo di questo modo di fare le cose, è in vigore dalla prima release (anni) e funziona ed è ben collaudato, e sorprendentemente ben scritto dato cosa / come fa.
Esiste un progetto separato che ha l'obiettivo di rivedere il sistema nel suo complesso e apportare miglioramenti delle prestazioni ove possibile. Assolutamente nessun problema con l'obiettivo qui.
Come parte di questo progetto, c'è stata una discussione che forse l'affermazione MERGE dinamica potrebbe essere più performante come una stored procedure statica. Forse potrebbero esserci dei miglioramenti memorizzando nella cache i dettagli di esecuzione, ecc. Io non sono un DBA, ma l'idea generale sembra fattibile. Possiamo fare un'analisi approfondita di ogni tabella e, se possibile, sintonizzare (aggiungere ulteriori indici).
Sebbene la conversione di alcuni elementi dinamici potrebbe avere senso, forse questo non è adatto a tutti e aggiungere gli artefatti e convertire tutti in statico è un sovraccarico che potrebbe non essere necessario. Quindi, per supportare questo, abbiamo discusso un'estensione del framework di configurazione esistente che consente un passaggio tra dinamico e statico. Tutto bene qui finora.
Passiamo quindi all'argomento del test e alla convalida della prestazione su larga scala. Generalmente l'approccio a questo era soddisfacente, ma ci sarebbe stato un ritardo nell'ottenere un ambiente adatto, con un set di dati adeguato (stiamo parlando di miliardi o righe / terabyte di dati)
Recentemente ho scoperto che l'intenzione è di implementare l'estensione al framework di configurazione e spingere questo live, senza veri test e nessuna convalida dei guadagni in termini di prestazioni. La ciliegina sulla torta per me è che non sarà effettivamente abilitato.
Il nostro processo di implementazione è attualmente piuttosto complesso e i rilasci alla produzione vengono eseguiti in modo standard indipendentemente dal payload. C'è una versione pianificata tra qualche mese e queste modifiche saranno pubblicate. La prossima versione non ha un programma go-live. Tutte le modifiche come questa avvengono come una distribuzione DACPAC, quindi se ci sono cambiamenti o meno, il processo confronterà il DACPAC con la produzione per ciascun componente.
Quindi, tra questa versione e quella successiva, queste modifiche esisteranno, non testate, ma inutilizzate, mentre viene eseguita l'analisi. Una volta completata, la prossima versione aggiornerà i dati di configurazione e tutti gli artefatti di supporto.
Sembra che stia combattendo una battaglia persa per convincere il project manager (tecnico) della terza parte che questo non è un buon approccio e abbiamo semplicemente chiesto perché non poteva essere rilasciato una volta che l'analisi è stata fatta, in la prossima versione (se applicabile ancora)
In genere sono curioso di sapere se sono troppo soggettivo per questo e non è davvero un grosso problema. Ho appena inviato un'altra email a una vasta cerchia di persone che hanno chiarito le mie preoccupazioni e sarà interessante vedere la risposta, suppongo che sarà sulla stessa linea di ciò che stiamo facendo comunque.
Qualche idea o commento?
Grazie