Evolutionary Databases - Design and Deployment

Matteo Baglini — Wed, 26 Mar 2008 14:09:00 GMT

Esistono diversi tools di Refactoring, in continua evoluzione, che aiutano uno sviluppatore agile ad evolvere in maniera incrementale il proprio codice. Lo stesso non si può dire per quanto riguarda il refactoring del database, si perchè anche quest'ultimo vuole la sua parte, quindi anche il design della del database deve evolvere in maniera incrementale, user story dopo user story. A questo punto nasce il probleblema di gestire questa naturale evoluzione all'interno del processo di sviluppo software.

L'approccio generalmente usato è quello di partire da uno script di base di crazione del database, da lì in poi per ogni user story che andrà a "toccare" il database verrà generato un script di aggiornamento che contiene le modifiche dalla versione precedente ed eventauli migrazione dati. Allo stesso modo lo script deve essere in grado di far "regredire" la struttura del database alla una release precedente. Tutti gli script seguenti a quello base saranno numerati, naturalmente in ordine crescente. Nel processo di build del progetto ci sarà un task che si occuperà di verificare la versione corrente del database e di eseguirein ordine tutti gli script necessari ad allineare il database alla nuova versione.

Esistono diversi tools in rete sia per il mondo .NET che per altri come Java e Ruby. Tutti si basano sulla filosofia che ho descritto prima, però hanno forme diverse di implementazione. Esiste una categoria di tools che utilizza gli script SQL, un'altra che utilizza file XML ed un'ultima categoria che utilizza file di codice (C#,VB.NET,ecc). Di seguito un elenco (sicuramente non completo) dei tools, basati su script SQL:

- dbdeploy.NET - http://sourceforge.net/projects/dbdeploy-net/
- dbdeploy - http://dbdeploy.com

basati su XML:

- MIGRATEdb - http://migratedb.sourceforge.net/
- LiquiBase - http://www.liquibase.org/

basati su codice:

- ActiveRecordMigration - http://wiki.rubyonrails.com/rails/pages/UnderstandingMigrations
- SubSonic Migrate - http://blog.wekeroad.com/2007/10/03/subsonic-migrate-me/
- RikMigrations - http://www.codeplex.com/RikMigrations
- Migrator.NET - http://code.google.com/p/migratordotnet/

Tutti questi tools si assomigliano molto, quello che secondo me può determinare la scelta di uno piuttosto che di un'altro è lo skill di chi dovrà creare l'update del database. Sicuramente se a modificare il database sarà un DBA, il quale ha una profonda conoscenza di SQL, il tool migliore sarà uno di quelli basati su script. Diversamente se sarà uno sviluppatore il tool più adatto sarà uno quelli basati su codice. Resta infine la categoria dei tools basati su file XML, a mio modesto parere, un ibrido senza nessun vantaggio, dato che richiede di racchiudere script SQL all'interno di appositi tag XML, complicandone la leggibilità.

Io personalmente ho iniziato ad usare dbdeploy.NET, consigliatomi da Marco Abis, che ringrazio. In fine segnalo questo post-guida all'uso di dbdeploy.NET e questo white paper Taking Control of your Database Development,utile a prescindere dal tool usato.

Technorati Tag: Refactoring,Agile,Database

Linkare FoxPro da SQL Server

Matteo Baglini — Fri, 12 Jan 2007 22:32:00 GMT

Oggi dovevo linkare un database FoxPro ad un' istanza di SQL Server 2005, esperienza per me nuova.

La store procedure per effettuare il link di fonti dati remote a SQl Server è la sp_addlinkedserver ,

mentre la sp_addlinkedsrvlogin serve a fare il mapping degli account tra l'istanza locare e la fonte remota,

indispensabile per eseguire le nostre query distribuite.

Le istruzioni per collegare FoxPro sono indicate nella seguente kb: http://support.microsoft.com/kb/207595/en-us

Technorati tags: FoxPro, SQL Server