Come salvare un modello di business da un database non corrispondente?

0

Esiste un'applicazione che coinvolge la fatturazione dei clienti aziendali per i servizi che i loro clienti utilizzano. Lo schema del database non riflette correttamente il modello di business. Ad esempio, su un determinato account, i servizi possono essere attivati e disattivati. C'è solo una colonna da rappresentare quando il servizio è stato disattivato e il codice sul posto aggiorna la stessa riga se il servizio viene riattivato piuttosto che aggiungere una nuova riga. Idealmente, una riga verrebbe aggiunta quando un servizio si attiva e aggiornato quando disattivato e ci sarebbe una colonna per rappresentare la data di attivazione.

Allo stato attuale, non esiste una solida cronologia di fatturazione per questi clienti aziendali, ma deve esserci da qui in poi. Impostiamo un "cutoff" per il modello precedente che è stato danneggiato e pulisci il tavolo? Aggiungiamo la colonna appropriata e iniziamo a lavorare correttamente con la tabella e controlliamo solo le righe che hanno una "data di attivazione" di null per rilevare legacy? Devono esserci diversi modi per gestirlo, ma non ho esperienza con questo tipo di situazione e vorrei conoscere alcuni approcci diversi.

    
posta 24.05.2013 - 07:28
fonte

2 risposte

3

"Of course the way things are now, there is no solid billing history due to the mistakes that were made."

Per quanto comprendo la tua domanda, lo schema del tuo database non ha alcune funzionalità (come le informazioni sulla cronologia), e hai problemi a cambiarlo perché non conosci il pieno impatto sul tuo sistema esistente.

Un approccio per affrontare questo tipo di situazione è risolvere il problema con estensioni compatibili con il modello di dati. Ad esempio, hai bisogno di una cronologia nella tabella di fatturazione? Aggiungi una nuova tabella "billing_history", con esattamente le stesse colonne della tabella di fatturazione e un ulteriore "numero di versione del record" nonché una colonna "Data di validità". Quindi aggiungi un trigger "dopo aggiornamento" a quella tabella che fa una copia del record di fatturazione corrente nella tabella "billing_history" ogni volta che il flag "disattivato" viene ripristinato su "attivato". Ora puoi aggiungere nuovi moduli per cercare, visualizzare e accedere a quella tabella cronologia e non devi modificare nulla nei tuoi moduli esistenti.

I dettagli potrebbero essere diversi nella tua situazione, ma spero che tu ne abbia l'idea.

    
risposta data 24.05.2013 - 08:28
fonte
0

Il tuo problema non è lo schema del database. È la domanda in cui il codice influenza i dati. Se è strutturato bene, puoi solo modificare codice e schema. Implementa una parte di codice che gestisce la cronologia mancante per i vecchi record e il gioco è fatto.

Il fatto che tu voglia inserire trucchi nello schema o nel database per evitare problemi sconosciuti significa che la vista del codice non è attualmente completa. Quindi si concentrerebbe strongmente sull'avere una buona visione di dove il codice agisce con lo schema.

Se lo trovi sparsi dappertutto, potresti prendere in considerazione di migliorare prima la struttura del codice invece di modificare direttamente la funzionalità di cui hai bisogno. Ciò creerà un risultato finale migliore.

Perché: pensa a tutte le modifiche che potresti dover apportare in futuro. Se hai bisogno di applicare trucchi ora devi prenderti cura di loro fino in fondo. Se lo aggiusti fin dall'inizio nel modo giusto, ti fa risparmiare tempo alla fine senza dover eseguire l'over-engineer.

    
risposta data 26.05.2013 - 11:44
fonte

Leggi altre domande sui tag