Come gestire versioni legacy di DAL e Database?

Question

Come gestire versioni legacy di DAL e Database?

#1 da (2 voti)

-1

Diciamo che hai un Database e un Data Access Layer ( DAL )

Il DAL verrà consumato da un diverso numero di prodotti che accedono a Database .

Man mano che il tempo passa, aggiungi nuovi campi e tabelle a Database , quindi aggiorna DAL dalla versione 1.0.0 alla versione 1.0.1 . Tutto va bene e bello:)

Il tuo team deciderà che più avanti sulla linea nella versione 1.0.13 che il campo non è più necessario, quindi elimina il campo dal database e incrementa il DAL in 1.0.14 .

Questo interromperà le versioni 1.0.1 , 1.0.2 , 1.0.3 ... e così via.

Un altro esempio:

Supponiamo che tu abbia un campo chiamato streetName in Database , e DAL è a 1.0.0 , ma in seguito, cambi il campo del nome della via in addressLine1 e incrementa la versione della% daDAL a 2.0.0 . Cosa succederebbe a 1.0.0 ? Chiaramente non funzionerà più perché non riesce a trovare il campo streetName in Database

Come si può risolvere questo problema? Più Databases per DAL versione? È questa anche la corretta direzione di approccio?

versioning database architecture

posta Dolan 12.10.2016 - 09:36

fonte

1 risposta

Leggi altre domande sui tag versioning database architecture

Nuovo sviluppo del progetto e linee guida e suggerimenti per git [chiuso] SMS per la messaggistica tra le applicazioni [chiuso]

score 2 · Accepted Answer

Questo non è l'approccio corretto, IMO. Lo scopo del DAL è di astrarre tutti i dettagli sulla memorizzazione dei dati. Come tale richiede un posto dove archiviare i suoi dati. Nel tuo esempio questo è un database con uno schema particolare.

Ora, per il controllo delle versioni, devi avere un database con lo schema corretto per il tuo DAL. Un approccio comune per ottenere questo è includere il codice che sappia come migrare dalle versioni precedenti alla versione corrente. In un punto del software corretto per la situazione, è possibile controllare la versione del database e intraprendere le azioni necessarie per ottenere lo schema corrente. Ovviamente questo potrebbe anche essere uno strumento separato o una procedura di configurazione di qualche tipo.

Per raggiungere questo obiettivo, sarebbe facile memorizzare un numero di versione nel database, in modo da sapere quale versione dello schema si sta guardando. Questo approccio consente di specificare cosa dovrebbe accadere in ogni scenario, non solo con le modifiche nello schema, ma anche con i dati.