Qual è la strategia consigliata per gestire un modello di database che cambia frequentemente durante lo sviluppo

5

Molti progetti hanno un modello di database da determinare durante lo sviluppo iniziale. Ciò potrebbe significare che molti SQL dovranno essere riscritti frequentemente. Qual è la strategia raccomandata per affrontare questo? Soprattutto quando vuoi sviluppare la tua applicazione RAD-like e con i requisiti finali che non vengono impostati su pietra? Principalmente progetti di giocattoli.

Uno scenario ideale sarebbe che non posso scrivere alcun codice SQL all'inizio del progetto e solo quando il modello di dati è più solido, in realtà si imposta il database per il progetto e si scrive SQL per esso. Durante la fase di sviluppo iniziale voglio solo essere in grado di modificare le mie classi di entità, senza dover cambiare il mio SQL più e più volte.

(Per il progetto che sto chiedendo, sto lavorando con Spring 4 e un database MySQL)

    
posta Kristof 04.12.2015 - 07:58
fonte

2 risposte

3

La tecnica che stiamo utilizzando nel mio progetto corrente (che probabilmente funzionerà per te) è l'uso di Liquibase . Tutte le modifiche al database vengono effettuate tramite i file di configurazione, che vengono registrati al controllo del codice sorgente e eseguiti automaticamente all'avvio dell'applicazione. Ciò aiuta a mantenere sincronizzato lo schema del database con il codice: ogni volta che si estrae la revisione più recente nel ramo, si ottiene la configurazione più recente del database. Diventa un po 'macchinoso se fai molto di più che aggiungere tabelle o colonne, ma IME la maggior parte delle modifiche apportate durante lo sviluppo di un nuovo sistema sono proprio così.

Credo che ci siano molti altri prodotti ORM in stile "code first", ma questo è l'unico con cui ho familiarità. Bene, questo e .NET Entity Manager, ma dal momento che stai usando Spring 4 presumo tu stia lavorando con Java. Tenere presente che altre soluzioni code-first potrebbero richiedere all'utente di eliminare completamente e ricreare il database quando lo schema cambia. Di solito questo non è un problema durante lo sviluppo iniziale, ma può diventare una seccatura in seguito.

    
risposta data 04.12.2015 - 15:13
fonte
0

Preferisco lavorare su sezioni verticali di funzionalità piuttosto che mantenere l'intero livello dati non implementato fino alla fine.

Molti ORM hanno una funzione di generazione di database. Non ha bisogno di essere sofisticato e supporta le differenze di schema DB, poiché nello sviluppo spesso non ci si preoccupa veramente dei dati e non si preoccupa di ricreare il DB da zero. Tuttavia, può essere una buona risorsa per il futuro quando l'applicazione va in modalità di manutenzione.

    
risposta data 04.12.2015 - 16:12
fonte

Leggi altre domande sui tag