Best practice per la riprogettazione di un database

Penso che tu sappia già come normalizzare un database.

Ciò di cui hai bisogno sono strategie per ridurre al minimo il rischio durante lo spostamento di tutto il software nel nuovo database.

Quello che sto suggerendo è più lavoro come compromesso per meno rischi.

Normalizza il database e crea un processo per popolare il database normalizzato con i dati del database originale. Il database originale sarà il database per inserimenti, aggiornamenti ed eliminazioni. Il database normalizzato sarà il database delle query solo durante la conversione.

Il tuo processo di popolamento dovrà essere eseguito tutte le volte che è necessario per i dati della query. Se i dati di un giorno sono accettabili, è possibile eseguire un processo di popolamento notturno. Se hai bisogno di più dati attuali, devi eseguire un processo di popolamento continuo.

Crea la porzione di query del tuo nuovo sistema ASP.NET, indicando il nuovo database normalizzato.

I risultati della query dal nuovo sistema devono essere confrontati con i risultati dell'interrogazione dal sistema originale.

Potresti fermarti a questo punto. Questa è una decisione aziendale, non una decisione tecnica.

A tuo piacimento, crei una nuova funzionalità di inserimento / aggiornamento / cancellazione nel tuo nuovo sistema ASP.NET. Quando crei la nuova funzionalità, spegni le parti del sistema originale che corrispondono. Ad un certo punto, nulla del sistema originale rimane.

I vantaggi della conversione in questo modo sono la riduzione del rischio creando prima la parte della query. Generalmente le funzioni di query sono semplici rispetto alla logica di business incorporata nella funzionalità insert / update / delete.

Si converte la funzionalità insert / update / delete un processo alla volta. Se c'è un problema con l'incomprensione della logica aziendale, può essere risolto mentre gli utenti utilizzano il sistema originale.

Dovrebbe essere ovvio che il tuo processo di popolamento sia assolutamente coerente.

Cerca di convincerli a contrarre lo sviluppo del nuovo sistema a un'azienda esterna, ci sono molte buone società di sviluppo che hanno le risorse per sviluppare correttamente le applicazioni più velocemente e meglio del tuo team limitato. Una buona compagnia di sviluppo sarà anche in grado di costringere i tuoi superiori a fare cose che potrebbero non fare se hai richiesto di farli, il PM della compagnia che viene pagato un sacco di soldi per sviluppare un'app ha molta più spinta per ottenere il coinvolgimento dell'utente rispetto al tipo IT molti livelli sotto l'autorità di gestione per organizzare tali cose.

Costa molto denaro in anticipo, ma pagherà molto tempo per disporre delle risorse adeguate per lo sviluppo e l'implementazione. Se riesci a far uscire una RFP, scommetto che le offerte che ricevi indicano che quello che stai cercando di fare è molto più complicato di quanto i tuoi manager realizzino.

Progetta il database normalizzato di cui hai bisogno con i tipi di dati necessari. Quindi la parte più difficile è la migrazione dei dati. Per prima cosa è necessario avere un piano per come si intende mappare dal vecchio al nuovo e cosa si intende fare con i dati che non soddisfano la nuova struttura. Ad esempio potresti avere dei dati è che ora non è identificabile se non disponi di vincoli di integrità adeguati. Potresti semplicemente non spostare quei dati o potresti aver bisogno di spostarli ma collegarli a un nuovo record principale chiamato "Sconosciuto". Se una data non è realmente una data reale, puoi inserire un valore null nel campo durante la migrazione? Avrai bisogno di risposte a questo tipo di domande. Vorrei suggerire che alcuni degli sviluppatori lavorino sul cambiamento della GUI per usare il nuovo database struture e altri per lavorare rigorosamente sulla migrazione. La migrazione è un compito enorme, richiederà molta abilità e molto tempo. Non lasciarlo come un ripensamento.

Poiché utilizzi SQL Server, puoi eseguire la migrazione effettiva tramite SSIS.

Crea una buona serie di casi di test in modo da poter confrontare i risultati con il vecchio sistema con il nuovo sistema.

Poiché hai così tanti anni di dati, potresti voler migrare in due parti. Prima migra la maggior parte dei dati e poi quando è il momento di andare in diretta, migra solo i dati modificati. Ovviamente è necessario mettere i controlli sul database per poter trovare i dati modificati che potresti non avere ancora. Puoi anche decidere di fare questo in questo momento se vuoi archiviare alcuni dati.

Mi trovo a confrontarmi con la riprogettazione degli schemi del database quasi ogni giorno a causa del supporto e dell'ulteriore sviluppo di diverse applicazioni legacy nate come file MS Access (.mdb) e poi cresciute fino a grandi database con diverse centinaia di tabelle ora localizzate su MS SQL Server ma con ancora il "decesso infantile" del progetto originale. Ecco alcune pratiche che ho trovato utili per me:

Cerca di minimizzare la superficie disponibile pubblicamente dello schema del tuo database.

Questo significa che dovresti provare a progettare alcune API pubbliche che rendi disponibili per le applicazioni esterne. Normalmente cerco di implementare i dati statici come viste (anche se sono basate solo su una singola tabella) e dati dinamici come viste parametrizzate o come stored procedure. Per le query di dati in cui è sufficiente un singolo valore, è possibile utilizzare anche le funzioni scalari.

Solo queste (viste, stored procedure e funzioni scalari) sono visibili ad applicazioni esterne (tramite ORM o direttamente) e utilizzate per tutte le operazioni CRUD. Questo schema viene quindi completamente bloccato, mentre internamente è possibile modificare le tabelle sottostanti, migliorare le procedure, ecc. - ciò non comprometterà la compatibilità con l'applicazione.

Cerca di ottimizzare i criteri del mondo reale, non quelli dei libri.

La normalizzazione è un argomento importante in ogni libro sulla progettazione di database. Ma nella vita reale ci sono casi in cui la normalizzazione non ti porta molto o addirittura rallenta il tuo database, ad esempio se hai alcuni dati che vengono ripetuti, ma la percentuale di ripetizioni è molto bassa ecc. Non sono contro la normalizzazione, quello che sto cercando di dire qui è che devi affrontarlo con un po 'di scetticismo e prudenza.

Registra la sessione di analisi e analizzale.

La riprogettazione del database basata esclusivamente sullo schema del database non è completa. Guarda il tuo database nelle sue dinamiche, prova a trovare i colli di bottiglia durante i test di carico e indirizza quelli. Nel caso di MS SQL Server è disponibile uno speciale Ottimizzazione guidata che può generare alcune raccomandazioni sui dati registrati traccia dell'attività.