Come dovrei affrontare la migrazione dei dati da una progettazione di database "cattiva" a una progettazione utilizzabile?

Question

L'attuale progetto che ho ereditato ruota principalmente attorno a una tabella non normalizzata.Ci sono alcuni tentativi di normalizzazione ma non sono stati posti i vincoli necessari.

Esempio:Nella tabella Progetto, c'è un nome cliente (tra gli altri valori) e c'è anche una tabella clienti che contiene solo i nomi cliente [nessuna chiave da nessuna parte].La tabella client viene utilizzata solo come pool di valori da offrire all'utente quando si aggiunge un nuovo progetto.Non c'è una chiave primaria nella tabella dei client o una chiave esterna.

"Modelli di progettazione" come questo sono comuni nello stato corrente del database e nelle applicazioni che lo utilizzano.Gli strumenti a mia disposizione sono SQL Server 2005, SQL Server Management Studio e Visual Studio 2008.Il mio approccio iniziale è stato quello di determinare manualmente quali informazioni necessitano di normalizzazione ed eseguire query Select INTO.Esiste un approccio migliore rispetto a un caso per caso o comunque questo potrebbe essere automatizzato?

Modificare:Inoltre, ho scoperto che un "numero di ordine di lavoro" non è un campo IDENTITÀ (numerazione automatica, univoco) e viene generato in sequenza e è univoco per ciascun ordine di lavoro.Ci sono anche alcune lacune nella numerazione esistente, ma sono tutte uniche.L'approccio migliore per scrivere una procedura di archivio per generare righe fittizie prima della migrazione?

Answer 1

L'approccio migliore per migrare verso un design utilizzabile? ACCURATAMENTE

A meno che tu non sia disposto a rompere (e riparare) ogni applicazione che attualmente utilizza il database, le tue opzioni sono limitate, perché non puoi cambiare molto la struttura esistente.

Prima di iniziare, pensa attentamente alle tue motivazioni: se hai un problema esistente (un bug da correggere, un miglioramento da apportare), procedi lentamente.Tuttavia, raramente vale la pena armeggiare con un sistema di produzione funzionante solo per ottenere un miglioramento che nessun altro noterà mai.Tieni presente che questo può giocare a tuo favore: se c'è un problema esistente, puoi far notare alla direzione che il modo più conveniente per risolvere le cose è alterare la struttura del database in Questo modo.Ciò significa che hai il supporto del management per le modifiche e (si spera) il loro supporto se qualcosa diventa a pera.

Alcune riflessioni pratiche...

Apporta una modifica alla volta ...E soltanto un cambiamento.Assicurati che ogni modifica sia corretta prima di procedere.Vale il vecchio proverbio “misura due volte, taglia una volta”.

Automatizzare Automatizzare Automatizzare ...Non apportare mai modifiche al sistema di produzione "in tempo reale" utilizzando SQL Server Management Studio.Scrivi script SQL che eseguono l'intera modifica in una volta sola;svilupparli e testarli rispetto a a copia del database per assicurarti di averli corretti.Non utilizzare la produzione come server di test: potresti eseguire accidentalmente lo script contro la produzione;utilizzare un server di test dedicato (se la dimensione del database è inferiore a 4G, utilizzare SQL Server Express in esecuzione sul proprio computer).

Backup ...il primo passo in qualsiasi script dovrebbe essere quello di eseguire il backup del database, in modo da avere un modo per tornare indietro se qualcosa va storto.

Documentazione ...se qualcuno viene da te tra dodici mesi, chiedendoti perché caratteristica X della loro applicazione non funziona correttamente, sarà necessaria una cronologia delle esatte modifiche apportate al database per facilitare la diagnosi e la riparazione.Il primo buon passo è conservare tutti gli script di modifica.

Chiavi ...di solito è una buona idea mantenere le chiavi primarie ed esterne astratte, all'interno del database e non rivelate tramite l'applicazione.Le cose che assomigliano a chiavi a livello aziendale (come il numero dell'ordine di lavoro) hanno l'abitudine inquietante di avere eccezioni.Introduci le tue chiavi come colonne aggiuntive con vincoli appropriati, ma non modificare le definizioni di quelle esistenti.

Buona fortuna!

Answer 2

Non riesco a pensare a un modo sensato di automatizzare questo .... qualche input umano è fondamentale in tali refactoring, se si desidera che l'uscita per essere utile.

Re numero di commessa; supponendo che si desidera che questo continui ad essere una colonna IDENTITY; si può forse compilare i dati, trova la più grande, quindi utilizzare ALTER TABLE per renderlo identità? Non ho alcun attrezzo TSQL a portata di mano, quindi non posso provare, purtroppo. In alternativa, basta considerarlo una chiave naturale .

Answer 3

1. Crea nuovo database il modo in cui si pensa che dovrebbe essere strutturato.
2. Crea una tabella ImportError nel nuovo database con le colonne come "oldId" e "errorDesc"
3. Scrivi una, procedurale, lo script leggibile semplice che tenta di selezionare una riga dalla vecchia struttura e inserirla nella nuova struttura. Se un inserimento non riesce, accedere come specifica un errore possibile al tavolo ImportError (in particolare, perché l'inserto fallito).
4. Eseguire lo script.
5. Validare i nuovi dati. Verificare se ci sono errori registrati al tavolo ImportError. Se i dati non è valido o ci sono errori, refactoring lo script ed eseguirlo di nuovo, possibilmente modificando la nuova struttura del database, se necessario.
6. Ripetere i passaggi 1-5 fino a quando si dispone di uno script di conversione solida.

Il risultato di questo processo sarà di avere: a) una nuova struttura db che viene convalidato contro la vecchia struttura e testato contro "pragmatismo"; b) un registro di potenziali problemi potrebbe essere necessario codice contro (come ad esempio gli errori che non si può risolvere con la vostra conversione perché richiedono una concessione nello schema che non si desidera)

(potrei notare che è utile per scrivere la sceneggiatura nel tuo linguaggio di scripting / programmazione di scelta, piuttosto che, per esempio, SQL).

Answer 4

Mi consiglia di utilizzare le stored procedure per aiutare il processo di traduzione.

In particolare:

1. Uno per uno, sostituire query utilizzate nel codice con le stored procedure. Nell'ambito della sostituzione, unità (o integrazione) Test scrivere contro le procedure memorizzate direttamente. Si consideri un a livello di codice StoredProcs classe di supporto per consolidare l'accesso al database lì.
2. Dopo tutte le query sono sprocs, è possibile refactoring del database, utilizzando i test di unità per assicurarsi che non stai cambiando comportamento previsto.
3. vantaggio:. Avrai quei test di unità per premunirsi contro le rotture future

Answer 5

Non ha detto se è necessario mantenere l'interfaccia dell'applicazione corrente, o se avete intenzione di riscrivere qualsiasi domanda nella domanda.

In entrambi i casi, lo farei

• la progettazione del nuovo schema
• lotti scrittura T-SQL, utilizzando i cursori se necessario, per migrare i dati

Cursori, pur non essendo una prima scelta nelle query operativi, sono grandi per questo tipo di applicazione, perché si può andare per il compito in modo molto strutturato. Questi script tendono ad essere molto leggibile, che è importante quando non funziona subito e si deve passare attraverso un paio di iterazioni.

Answer 6

È possibile utilizzare SQL Server Integration Services (SSIS) che fa parte di SQL Server 2005 per aiutarvi con la migrazione. E 'utilizzato per trasferire i dati da una forma all'altra:

http://en.wikipedia.org/wiki/SQL_Server_Integration_Services http://www.microsoft.com/sqlserver/2005/ it / us / integrazione-services.aspx

Answer 7

Giusto per aggiungere un semplice suggerimento. Quando hai il tuo Entity Relationship schema su una A4 o A3 di fronte a voi una corretta normalizzazione significherà non molti a molti rapporti. Controllare questo o almeno il sito anche.