C'è qualche speranza di scrivere un buon codice su un database orribilmente progettato?

Ecco la mia situazione. Uno dei numerosi programmi che ho ereditato di recente è stato creato con un orribile database sul backend. Apparentemente i stimati creatori non apprezzarono i concetti relazionali. Una tabella per ogni client, denominata come ID client univoco. Ottantatre campi con nome criptico. Il codice è tutto procedurale con dozzine di istruzioni SQL in linea concatenate.

Dato che non ci è stata fornita un'importante applicazione ausiliaria che viene eseguita dallo stesso database, mi è stato assegnato il compito di ricrearlo da zero. Sono un solo sviluppatore, che non è nemmeno la mia principale responsabilità in quanto almeno la metà del mio tempo è occupata da operazioni. C'è una scadenza inevitabile fissata tra 30 giorni.

Nonostante la mia inesperienza, sono certo che avrei potuto progettare questo database e l'applicazione esistente molto meglio di quanto non fossero, ma non credo davvero che sia realistico per me modificare il database, regolare l'applicazione esistente ed essere sicuro di non averlo fatto Non interrompere nulla mentre è necessario creare l'applicazione aggiuntiva così rapidamente.

Quindi supponiamo che io sia bloccato con il terribile database. Avendo bisogno di lavorare con una struttura così cattiva, qualsiasi cosa che scrivo conforme ad essa aggiungerebbe semplicemente al mucchio di debiti tecnici da accantonare fino a quando qualcosa non si rompe completamente o sono necessarie nuove funzionalità? Come potrei affrontare questa situazione e ricavarne qualcosa di buono oltre a un'applicazione, si spera, funzionale?

modifica: Nel caso qualcuno fosse interessato, abbiamo finito per eliminare questo orribile database e l'applicazione che lo eseguiva. Abbiamo esternalizzato la creazione dell'applicazione ausiliaria (non ero coinvolto nella creazione di questo) alla fine due diversi appaltatori che entrambi hanno finito per cadere su di noi, senza realizzare nulla. Ho finito per correre fuori da tre giorni un trucco orribile e parzialmente funzionale di una correzione che è ancora in uso oggi.

C'è speranza, ma è una battaglia in salita, soprattutto se nessuno si rende conto che il design del database è orribile. Puoi provare a sottrarre la cattiveria con strati di astrazione, ma è probabile che non varrà la pena combattere.

Il mio consiglio sarebbe di creare abbastanza astrazioni sul database che l'applicazione stessa sia pulita e correttamente progettata; in questo modo se è possibile correggere il database, l'applicazione non sarà interessata dal momento che non importa come è stato progettato il database.

Questo è l'approccio che normalmente utilizzo quando si tratta di un database che è in atto e, il più delle volte, progettato con zero pensiero. Alcune applicazioni scelte dei modelli di repository o gateway, con alcuni livelli di servizio per comunicare con il gateway / repository, dovrebbero aiutare a mettere in quarantena la progettazione scadente.

Costruisci un livello di interfaccia che gestisca tutto il materiale DB e poi scrivi la tua app per interfacciarlo. Nel caso in cui il database venga "riparato", è sufficiente sostituire / aggiornare la "interfaccia". Questo approccio mi ha risparmiato un sacco di tempo quando ho a che fare con un database difettoso o un database che alimentava altre applicazioni e non poteva essere disturbato.

Ahi ... Hai ereditato un disastro da incubo, hai 30 giorni per renderlo utilizzabile per la tua organizzazione e metà della tua giornata è occupata da attività operative?

Sono sicuro che potresti refactoring ma certamente non in quel lasso di tempo.

Per rispondere alla tua domanda, non penso che tu possa effettivamente scrivere un buon codice su un tale design. Il debito tecnico è già troppo. Se fossi in te, vorrei hackerare le funzionalità che potevo e premere per un refactoring completo in un secondo momento quando hai più tempo e persone nel tuo team per affrontarlo meglio.

Stai solo attento a spingere per il refactoring. A volte un superiore prenderà la decisione di acquistare un codice sorgente di prodotti e diritti di proprietà e non vogliono pensare di aver sprecato completamente i loro soldi in spazzatura. Questo è stato il caso per me in un lavoro che ho avuto. Sfortunatamente i manager prendono decisioni sull'acquisto di software come questo e non ottengono mai un coinvolgimento tecnico per valutare ciò che stanno acquistando e vedere se è gestibile e ha una grande quantità di debito tecnico. In questo caso la decisione sbagliata è politica e spingere per il refactoring può mettere a repentaglio il tuo lavoro.

I database possono essere refactored proprio come altri codici. Correggi la parte interessata dal codice necessario per scrivere e scrivere i test per assicurarti che nient'altro si rompa. Fai un po 'alla volta, proprio come qualsiasi altro refactoring. C'è un buon libro sul refactoring del database che potrebbe aiutarti a iniziare a ripulire il casino. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Ce ne sono anche altri, ma personalmente ho letto e lavorato con le tecniche in questo.

E non dimenticare che puoi ristrutturare il modo in cui devi interrogare il database creando viste per fare il brutto lavoro di trasformazione per te in una struttura più facile da interrogare.

Per ottenere il massimo profitto dal tuo dollaro, crea viste aggiornabili per ripristinare un po 'di "relazionalità" e fornire nomi di colonna più significativi.

Una possibilità sarebbe quella di creare un secondo database strutturato (almeno più vicino a) come desideri e impostare la replica tra i due database. Quindi è possibile scrivere il codice sul nuovo database e lasciare intatto il database esistente (e l'applicazione), da gestire quando si ha più tempo.

Sinceramente, è ancora aperto a molte domande se è possibile farlo in circa 15 giorni di lavoro. In particolare, è probabile che dipenda dal fatto che sia necessaria una replica bidirezionale (ovvero, la nuova applicazione aggiornerà effettivamente i dati) o solo un modo (la nuova applicazione consente solo alle persone di visualizzare i dati). Quest'ultimo caso è (ovviamente) drammaticamente più facile da affrontare.

Se hai bisogno di una replica bidirezionale, è probabile che non sia abbastanza tempo per fare il lavoro. In particolare, la replica bidirezionale che comporta la trasformazione sostanziale della struttura non è mai banale e gli strumenti disponibili spesso la supportano in modo piuttosto scadente (ad esempio, dover scrivere a mano tutto l'SQL per tutte le trasformazioni dei dati in entrambe le direzioni).

Se hai solo bisogno di un modo, è proprio nel punto in cui potrebbe essere possibile. Dipenderà anche un po 'dal fatto che ti sia permesso spendere soldi o meno - ci sono alcune applicazioni di data warehousing che sono destinate esattamente a questo tipo di attività che probabilmente lo renderebbero un po' più veloce e più facile da gestire, ma la maggior parte di essi non è economica.