Nelle scorse settimane ho scritto di MongoDB e di altri database NoSQL; proprio provando questi prodotti mi sono tornate alla memoria le infinite discussioni sulla necessità di uno sviluppo database independent, ovvero di uno sviluppo non legato ad uno specifico database.
C'è stato un periodo in cui pareva che un'applicazione web (per esempio un CMS) dovesse supportare diversi DBRM e ci fu quindi un proliferare di framework, classi e script che permettevano proprio di fare questo: cambiare database con qualche aggiustamento nelle configurazioni.
Per un po' la cosa mi aveva convinto: con questo tipo di approccio si ottengono buona portabilità e forte indipendenza da specifici vendor, cosa che tre parole rendono molto ragionevole: Sun, MySQL, Oracle.
Poi, un po' per volta, i prodotti in ambito FOSS sono maturati attorno ad uno specifico DB (di solito MySQL), facendo del database e della logica PHP un corpo unico e inscindibile.
Personalmente, sono per uno sviluppo database oriented, fortemente legato al database: più è complesso il prodotto, infatti, maggiore è la necessità di fruttare a pieno le caratteristiche peculiari del database scelto, come tipi di dato, dialetti SQL, store procedure. Se si considera il database parte integrante dell'applicativo, e non solo un luogo dove mettere i dati, ogni caratteristica del DB deve essere sfruttata a pieno, perché solo così si otterrà un'applicazione performante in ogni componente.
Insomma, attualmente non vedo il modo di scrivere un'applicazione complessa, articolata e ottimizzata senza fare una scelta di fondo anche sul database e l'occasione di lavorare sui prodotti a schema libero, dove le procedure di accesso ai dati sono proprie di ogni database (che appunto non usano SQL) mi ha indotto a chiedermi se l'approccio database independent non sia stato un abbaglio o un'utopia o solo una perdita di tempo.
