Trattare il database agilmente
Sulla mailing list di Extreme Programming si parla di strumenti per gestire il refactoring dei database. Secondo me lo strumento più carino sono le migrations di Rails… ma a parte questo, il mio contributo in mailing list è stato il seguente.
A proposito di database refactoring, ci sono alcune pratiche essenziali:
* ogni sviluppatore ha un suo database di sviluppo personale
* ogni sviluppatore ha un suo database personale per i test automatici
* è possibile ricostruire entrambi i database, aggiornando lo schema in development e in test, e caricando i dati di base, con un solo comando
* gli sviluppatori hanno la facoltà di modificare lo schema dei dati!
Ottenere questo è in parte un problema politico; alcuni DBA scricchiolano quando gli si chiede di creare così tanti database; oppure pretendono procedure burocratiche per modificare lo schema, o addirittura impongono schemi di nomenclatura assurdi (ho lavorato in un progetto dove ogni tabella aveva nomi tipo t0345customers, e i campi avevano nomi tipo int0345customer_id). In parte è un problema tecnico, che però si può gestire con script.
Se queste pratiche di base sono rispettate, allora diventa possibile fare evolvere lo schema dei dati con degli script progressivi. Ad esempio, prendendo spunto dalle migrations di Rails, in un progetto Java avevamo script con nome 001_create_customers.sql, 002_add_foobar_column.sql, eccetera; la nomenclatura permette di caricarli tutti nella sequenza corretta con un singolo comando:
cat ???_*.sql | mysql foo_development
Abbiamo trovato utile mettere in ciascuno dei file un istruzione tipo
update schema_info set version = 3;
in modo che in ciascun database abbiamo un informazione che ci dice a che livello si trova.
Non c’è bisogno di un gran che di tecnologia per usare queste pratiche, e secondo me permettono di risolvere una buona parte dei problemi di evoluzione della base dei dati.
September 7th, 2007 at 11:17
Ottima l’idea degli script incrementali per tenere traccia di tutti gli aggiornamenti del db, la settimana scorsa a lavoro riflettevo proprio su questo problema dopo un aggiornamento alla struttura del database. Ottima anche l’idea del doppio db, uno per lo sviluppo e uno per i test, ora come ora ne utilizziamo soltanto uno per lo sviluppo/test. I test alla fine si assicurano di fare il cleanup di tutti i dati aggiunti, ma effettivamente avrebbe più senso che il db fosse creato da zero ogni qual volta i test venissero eseguiti, o comunque svuotati alla fine dei test.
September 10th, 2007 at 17:41
Sempre interessanti i tuoi spunti.
Purtroppo alcune di queste osservazioni dovrebbero esser scontate (es: separare db test automatici dal development, !!separare development da production!!), ma purtroppo mi imbatto ancora in sviluppatori che commentano con un “ma che noia questi test automatici, non possiamo skipparli?”… figuriamoci a gestire in modo ordinato anche la parte db :-(
My .02
M