Refactoring o aggiornamento di database per gestire nuove funzionalità

C'è un intero libro scritto sul refactoring del database. Proprio come con il refactoring del codice, esistono metodi standard per eseguire il refactoring del database. L'unica differenza è che quando si esegue il refactoring del codice, non è necessario considerare lo stato dell'oggetto / codice, mentre nei database si devono considerare i dati, perché la perdita di dati non è buona per gli utenti (o per chiunque, in realtà ).

Puoi leggere ulteriori informazioni sul refactoring del database qui .

Il codice di refactoring è semplice: basta modificare il codice ed eseguire i test di regressione.

Il refactoring dei database è difficile - devi spostare (una quantità potenzialmente enorme di) dati in giro, assicurati che nessuno di essi venga eliminato, assicurati che i vincoli siano mantenuti nel nuovo schema. E, se hai i requisiti di controllo sui dati, devi essere in grado di spiegare perché è organizzato in modo diverso ed essere in grado di abbinare i dati del pre-refoctor ai dati post-refactoring. Inoltre, nessuno dei tuoi vecchi backup corrisponderà al nuovo schema, che rappresenta un ulteriore rischio.

Cose spaventose.

C'è una linea sottile tra la spesa di un lungo periodo di over-engineering e l'investimento di un po 'del tuo tempo per aggiungere solo alcune funzionalità per farti risparmiare una notevole quantità di tempo in futuro.

Penso che la teoria sia che se si include una tabella di collegamenti per supportare una relazione molti a molti tra 2 tabelle, allora anche se nei dati esistono solo relazioni da molti a uno, tutti scriveranno l'SQL in modo tale che se mai molti a molti sono supportati, tutto "funzionerà".

In pratica non ho scoperto che questo è vero, ma suppongo che SQL sia più vicino a ciò che deve essere per supportare molti a molti rispetto a quanto sarebbe stato altrimenti.

Ma per ottenere specificamente la tua domanda, in realtà è una buona dose di dolore che converte una relazione da 1 a molti a molti a molti. Il motivo è che SQL è non progettato con lo stesso tipo di obiettivi di incapsulamento degli oggetti, e la maggior parte delle query utilizza più tabelle sul livello del database di quanto sarebbe comodo avere un oggetto nel livello aziendale con visibilità a.

Quindi una modifica di una relazione molti a molti avrà un impatto su ogni query che coinvolge le 2 tabelle originali, spesso un effetto a cascata molto più ampio di quello che accadrà sul livello aziendale. Quindi le persone fanno di tutto per impedire che ciò accada.

IMHO questo non sarebbe necessario se avessimo un linguaggio migliore di SQL per specificare l'algebra relazionale. Se fosse fattibile costruire una query SQL pezzo dopo pezzo per oggetti che non avevano bisogno di visibilità per ogni tabella della query, ciò non accadrebbe. Cose come LINQ (a SQL o alle Entità) tentano di risolverlo, ma è una soluzione complessa molto e difficile da ottimizzare (e sono stato a gruppi di utenti DBA in cui LINQ è menzionato e un collettivo gemito sale ogni volta). Sogno un linguaggio di database universalmente supportato con funzioni di algebra relazionale di prima classe ...

Nel frattempo, sì, puoi refactoring da 1-a-many a many-to-many, ma può essere molto lavoro.

Di solito lo spiego in questo modo ai PHB: il codice è il muro e il tetto, il database è il fondamento.

È possibile spostare i muri e cambiare il tetto. Cambiare le fondamenta richiede molto tempo per scavare e ricostruire le pareti e il tetto.

Ciò che gli sviluppatori inesperti (e professori universitari) dicono essere "sopra l'ingegneria" è ciò che gli sviluppatori esperti chiamano "prove future". Nonostante ciò che dicono le specifiche, sapete cosa cambierà probabilmente durante l'ALM o dove si verificheranno i problemi di prestazioni, quindi è meglio iniziare con la struttura della tabella.

L'implementazione di script di aggiornamento sui server dei clienti è un progetto non banale e ciascuno dei DBA dei clienti si trova dappertutto e desidera che il triplo controlli tutto. Dopo tutto, alcune colonne e tabelle in più non sono poi così male.

La regola generale è se una relazione è uno a uno, ma può in futuro essere molti a molti, quindi renderlo un molti a molti.

Il dipendente / reparto è un classico esempio. Nella maggior parte delle piccole aziende questa è in effetti una relazione uno a molti la maggior parte del tempo . Tuttavia c'è quasi sempre una situazione in cui diventa molti a molti - uno dei tuoi ingegneri passa alla gestione, ma è ancora responsabile del supporto di un prodotto che ha sviluppato mentre era in ingegneria, oppure, uno dei tuoi addetti alle vendite si è trasferito a lo sviluppo del prodotto, ma, poiché ha una stretta relazione con un cliente importante, è ancora responsabile del venditore per quel cliente.

Non costa molto di più se uno a molti è implementato come molti a molti - ma il refactoring di un database e un'applicazione per supportare molti a molti è costoso e irto di difficoltà.

Ci sono due modi per guardare il design del software (e probabilmente molte altre cose) - Una vista tattica o una visione strategica. Ognuno ha i suoi vantaggi e svantaggi.

Anche con le modifiche del software OO è ancora un problema, non solo la parte di codifica è difficile, ma il processo di promozione di un cambiamento alla produzione in un ambiente di reclamo (dato lo stato attuale della tecnologia) è irreale per i sistemi di grandi dimensioni che sono dovrebbe funzionare 24/7.

Seguo il mio principio che dice: " Quando possibile, progetta artefatti software condivisi strategicamente " - Può sembrare che in qualche modo vada contro il principio YAGNI, tuttavia , Questa è la mia opinione. Questo approccio garantisce meno ri-lavoro sul costo della complessità e delle risorse.

Nel tuo caso, le attività richieste per aggiungere una nuova tabella di giunzione includeranno: progettazione, approvazione del progetto, modifica dello schema, riscrittura di diversi metodi per CRUD per 3 tabelle (con l'eccezione di alcune letture), creazione di indici, creare GUI per CRUD per la nuova tabella, per consentire all'utente di selezionare i PK in creazione, aggiornamento della nuova tabella, ecc. Oh, e comunque non dimenticare i test unitari, i test di accettazione degli utenti, i test di sistema e la produzione promozione.

Se ciò non bastasse, il vero incubo deriva dalla perdita di informazioni. Se non si dispone della tabella di giunzione e si è deciso di acquisire le date in cui si è verificata l'associazione / separazione tra un dipendente e un dipartimento, non sarà possibile popolare automaticamente la data sulla tabella di giunzione. Devi inserirli manualmente (se hai i dati).

Quindi, è meglio prevederlo fin dall'inizio.

Come sopra ha detto Matthew, il refactoring / cambiamento dei database è spesso più complicato rispetto al software, in quanto anche la gestione dei dati deve essere presa in considerazione. Esistono tecniche che possono aiutare ad assicurare che tu abbia una suite appropriata di test delle unità di database, disaccoppiare le applicazioni client dallo schema di base utilizzando una 'API DB' - sprocs / views ecc.