Devo refactoring questo database? Come posso farlo?

La chiave per un refactoring è di non rompere l'interfaccia. Un database ha una seconda preoccupazione di non perdere i dati. Se il database del server sql è principalmente tabelle, è possibile assegnare le tabelle effettive a uno schema diverso (probabilmente uno più descrittivo di dbo) e quindi creare una vista con il vecchio schema.TabellaTabella.

Ora hai un modo per bufferizzare le modifiche apportate in modo incrementale all'applicazione dal vecchio al nuovo sistema.

Esempio: eliminazione del campo non utilizzata. Inizia con la parte o le parti dell'app che modificano i dati. Se questo campo non ha codice di modifica, puoi rilasciare il campo dalla tabella (quella con tutti i null), ma nella vista:

Select Null as OldFieldName from NewSchema.OldTableName;

Considero questo punto di vista, per iniziare a essere un codice di auto-documentazione. Se stai per iniziare a documentare i nomi delle colonne, perché non iniziare il processo di dare loro nomi significativi?

Esempio: rinomina colonna Non sarebbe così difficile rinominare la colonna nella tabella, ma mantenere il vecchio nome come nome alias nella vista.

Select NewColumnName as OldColumnName from NewSchema.OldTableName;

Nessun motivo per cui non potresti fare lo stesso con le tabelle.

L'applicazione ora può essere modificata in modo incrementale per passare dai vecchi nomi e colonne della tabella (La vista) alla nuova tabella e alle nuove colonne (a meno che non venga rilasciata). La vista può quindi essere rilasciata con il codice nella cronologia del controllo sorgente se qualcuno vuole vedere come è la tabella precedente.

Spostare le colonne in una tabella diversa può essere gestito nella vista, ma con sql server una vista non è considerata aggiornabile, se tenta di modificare i dati in più di una tabella in una volta. Un modo per aggirare questo è mantenere la vecchia colonna, ma mettere un trigger sulla tabella per copiare automaticamente tutti i dati da questa colonna alla nuova colonna nell'altra tabella. Dopo che tutto il codice dell'app è stato modificato per utilizzare la nuova colonna, è possibile rimuovere la vecchia colonna e il trigger.

Ricorda, c'è molto di più nel database rispetto allo schema, quindi devi anche tener conto delle modifiche ai dati.

Assumersi la responsabilità del proprio database senza rompere il modo in cui viene utilizzato è un lavoro difficile. Penso che questo metodo ti dia la possibilità di avere più controllo e comprensione del database quando dai nomi appropriati e coordinate una strategia con il team di sviluppo per sbarazzarti di cose che non ti servono più.

Certamente non vuoi cambiare un database senza autorizzazione e comprensione di cosa sta usando quel database. Ho visto implementazioni di codice che codificano l'ordine e il numero di colonne, e tanto quanto rimuovere una colonna causerebbe l'esplosione di tutta la cosa maledetta, perché adesso col [4] è qualcosa di diverso, o non c'è col [9] (e non controllano gli indici prima dell'accesso).

Ho visto spesso spazzatura come questa:

// DB: ID - FIRST_NAME- TEST_FLAG - LAST_NAME

cols = get_cols(result);

firstName = cols[1];
lastName = cols[3];

Elimina la colonna TEST_FLAG inutilizzata e kaboom! O peggio, se l'ultima colonna non è in uso e si cambia improvvisamente una colonna centrale, le cose verranno assegnate in modo errato, come avere le informazioni private assegnate ai campi dati pubblici. Passa lo schema DB a qualcosa di simile a questo:

DB: ID - FIRST_NAME- TEST_FLAG - LAST_NAME - USERNAME - PASSWORD

... e uh oh, ora viene mostrata la password di tutti se hai un elenco di nomi utente pubblicamente accessibili o qualcosa del genere, perché ora i cols sono passati a 1.

Codice errato, sì. Codice reale? Purtroppo, anche sì. Non vuoi essere quello che fa crashare un intero sistema perché hai preso un'ipotesi non autorizzata.

Un altro, meno terribile, esempio è con il codice relazionale dell'oggetto, dove TEST_FLAG potrebbe essere mappato su un oggetto, e anche se non viene usato il codice si aspetta ancora che sia presente e creerà un errore (forse non con grazia) se c'è una mancata corrispondenza.

Ora, non c'è niente di sbagliato nel documentare questo sistema e prendere appunti per il miglioramento, e quindi discutere di una fase di refactoring durante la migrazione a un sistema migliorato. Ma dovrai testare il sistema in modo estensivo, in quanto questo tipo di assurdità può essere presente ovunque in qualsiasi sistema che utilizza il database. La maggior parte degli IDE automatici / intelligenti non è in grado di rilevare questo tipo di errore, in quanto non sono configurati in modi che conoscono lo schema del database.

Tutto questo può essere risolto con un codice migliore e più resiliente, ma molti sviluppatori non hanno mai imparato a creare codice che non si rompa con la minima modifica allo schema di un database.

Il tuo compito sta documentando. Quindi attenetevi ad esso.

Dato il chilometraggio del database, la probabilità che tu veda - e non sia d'accordo - con alcuni aspetti di esso è molto grande.

Quindi, mentre svolgi questo compito, prova a fornire la documentazione - lo stato effettivo - e le tue considerazioni - come può essere migliorato - alla fine del compito.

IMHO stanno cercando di sapere come stanno le cose adesso per tracciare una strategia per migliorarla.

Supponendo che tu abbia il permesso di cambiare il database, dovresti refactoring solo che c'è abbastanza budget, non solo per refactoring stesso, ma per un test affidabile (!) dopo la modifica. Valuta inoltre il rischio di alcuni tempi di inattività dei tuoi sistemi di produzione quando scopri che qualcosa non funzionerà più dopo la modifica e assicurati che la tua azienda possa permetterselo.

Questi punti fanno sì che un refactoring di un db di dieci anni spesso sia molto più costoso del previsto. Cancellare la colonna del database è la parte facile. Ottenere una certa sicurezza che questo cambiamento probabilmente non rompere nulla è anche facile. Assicurarti che veramente non abbia infranto nulla è difficile!

1) Dovresti refactoring?

Questo dipende molto dalla cultura del tuo posto di lavoro. Alcune organizzazioni si aspettano che gli sviluppatori si assumano la responsabilità di eventuali problemi rilevati e si assumano la responsabilità di trovare una soluzione. Altri si aspettano che tu faccia solo ciò che sei stato incaricato di fare (documentare il database) e assolutamente non di più. In ogni caso, il refactoring di un database è un'operazione alquanto rischiosa, quindi è una buona idea informare almeno e ottenere il buy-in dai team che saranno potenzialmente interessati.

Leggendo le altre risposte sembra che il secondo tipo di organizzazione sia il più comune. La mia esperienza è quella delle start-up e le organizzazioni più piccole sono spesso del primo tipo, mentre quelle più grandi sono più del secondo tipo. Penso che questa sia una buona opportunità per te per scoprire in quale tipo di organizzazione ti trovi. Quindi chiedi al tuo superiore o alla tua squadra quali azioni dovrebbero essere eseguite quando vedi un problema simile - inizia a risolverlo, segnalalo a qualcun altro, o semplicemente ignoralo e concentrati sul compito che ti è stato assegnato. Comprendere questi fattori culturali ti aiuterà molto nel tuo lavoro.

Ovviamente, se non hai un superiore di mente tecnica che è in grado di effettuare questa chiamata, allora devi chiamare tu stesso, e quindi decidere quale tipo di organizzazione desideri.

2) Come procedere?

Stabilisci una panoramica di tutte le applicazioni che utilizzano il database, inclusi report, script SQL pianificati e qualsiasi altra cosa che possa essere influenzata dal database.

Identificare come queste applicazioni accedono al database. Attraverso uno strato ORM? Attraverso query SQL dirette? Attraverso stored procedure e viste? SQL dinamico? È select * from prevalente?

Il tuo approccio dipenderà molto dalla risposta a queste domande.

Se hai una singola applicazione che accede al DB attraverso un ORM, allora è facile: puoi identificarti attraverso l'analisi del codice se il codice in qualche modo dipende dalle colonne obsolete e, in caso contrario, rimuovili. La ridenominazione è anche abbastanza facile in quanto è sufficiente aggiornare la mappatura insieme al database.

Se hai più applicazioni o applicazioni che generano SQL in modo dinamico, diventa più complicato. Suggerirei di creare una serie di viste che rappresentassero il modo in cui il database dovrebbe apparire (rimuovere le colonne obsolete, rinominare le colonne, ecc.) E quindi è possibile migrare gradualmente le applicazioni per utilizzare queste viste. Quindi, quando tutte le applicazioni vengono migrate, è possibile modificare la tabella sottostante per rispecchiare le visualizzazioni. Il tipo di sistema di database che utilizzi influirà su quanto è possibile aggiornare o inserire in tali viste.

Potrei entrare in molti più dettagli, ma senza sapere di più sulla tua configurazione particolare sarebbe eccessivamente ampio. Forse se hai modificato la domanda con le risposte alle domande precedenti, otterresti risposte più utili.