Che fine ha fatto l’approccio “database independent”?
Venerdì 5 Marzo 2010 - 07:55
di Andrea Ganduglia
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.
Categoria: PHP e Open Source | Permalink
Commenti
1
Sono d’accordo, uno strato aggiuntivo non fa che limitare la progettazione alle sole caratteristiche comuni.
Poi ogni db server ha i suoi trucchi per migliorare le prestazioni, e quindi la struttura ottimale della base dati varia a seconda di questo.# - postato da Mik - 05 Marzo 2010 - 08:30
2
Ciao,
dipende dal framework se ti affidi a mvc come symfony, zend, rails ecc…. lo strato orm esiste sempre e quindi l’applicazione è più facilmente portatile su altri database# - postato da sasuke - 05 Marzo 2010 - 08:39
3
Mi ricordo uno video realizzato da Envylabs, dove promuovendo ActiveRecord dicevano:
“Metti che domani vuoi passare da MySQL a PosteSQL”Ok ma adesso seriamente, chi lo fa davvero?
Voglio dire, sono sicuro che a più di qualcuno è successo di dover migrare il proprio sistema da un RDBMS a un altro, basti solo pensare a chi usa SQLite in locale e fa il deploy su un RDBMS più complesso, però credo che è un’eventualità così remota e che porta con se talmente tanti fattori che il fatto di poter cambiare o meno tipo di database con una riga di configurazione diventa quasi un fattore secondario…# - postato da davide - 05 Marzo 2010 - 09:33
4
Io penso che un approccio db oriented ormai sia preferibile ad uno indipendent.
Poi dipende sempre dall’ambito, in genere si creano applicativi su misura e quindi la scelta di un db specifico.
Per applicazioni complesse(vedi wp) è addirittura obbligatoria la scelta del database.# - postato da Filippo Matteo Riggio - 05 Marzo 2010 - 09:34
5
Ok, allora vai a piazzare il tuo applicativo che fa uso intensivo delle peculiarità - diciamo - di MySQL presso una Pubblica Amministrazione centrale dove tutto il resto con cui devi integrare fa capo - diciamo - a Oracle … :) credo che rimpiangeresti l’aver abbandonato l’indipendenza dal database :)
non siete d’accordo?
# - postato da William Ghelfi - 05 Marzo 2010 - 09:50
6
@William
Che discorsi, se lo fai su misura per loro mi sembra il minimo informarsi su cosa utilizzano, così usi già tu in partenza Oracle. Se invece è qualcosa di open source scelgono loro e sono problemi loro.
# - postato da davide - 05 Marzo 2010 - 11:35
7
Concordo che dipende dal caso specifico: quando le performance diventano un problema, é fondamentale poter sfruttare le feature specifiche del db.
Drupal ad esempio supporta di default pgsql e mysql (e sqlite dalla 7), ma i siti che necessitano di alta scalabilitá usano spesso PressFlow, una distribuzione di drupal dove, tra le altre ottimizzazioni, c’e’ proprio la rimozione del supporto di molteplici db e l’utilizzo efficace di MySql e del suo sistema di replica.
8
esistono due scenari, quello di “prodotto” che desideriamo vendere a quanti più clienti possibile e configurare con poco sforzo e quello di singola applicazione altamente ottimizzata per un ambito specifico e un ambiente specifico.
a seconda dello scenario in cui ci muoviamo la risposta è ovvia# - postato da devsmt - 05 Marzo 2010 - 11:52
9
Bellissimo argomento. Io non ne ho traccia nei prodotti che uso!
10
Dipende, ma tendenzialmente sono in disaccordo.
Secondo me lo sviluppo dovrebbe essere il piu’ possibile database independent.
Poi, se motivi specifici lo richiedono (es: performance) si possono sfruttare le particolari funzioni del DBMS in uso.Non credo si possa definire abbaglio o perdita di tempo la ricerca della portabilità.
Certo, in alcuni casi specifici non è una proprietà necessaria di un sistema, ma appunto dovrebbero essere eccezioni.
Soprattuto per la portabilità rispetto al database: non è così remota la necessità di cambiare DBMS!# - postato da Andrea Zilio - 05 Marzo 2010 - 17:01
11
Secondo me il punto cruciale parte dalla contrapposizione: “Generic vs. Specific”.
Utilizzando un web framework (come Django, Zend, Symphony, etc.), non potrà che essere la prima logica a prevalere. I web framework vengono sviluppati per essere il più generici possibile, per offrire uno strumento di sviluppo il più rapido e agevole possibile e, perchè no, anche portabile.
Se devo sviluppare una applicazione e devo fare i conti con determinati paletti (scalabilità, performance, infrastruttura), ecco che la filosofia ‘generic’ che è alla base di tutti questi web framework, va a farsi fottere e subentra un discorso specialistico.
In questo caso allora, sarà essenziale sviluppare l’applicazione avendo bene in mente quale sarà l’infrastruttura che la ospiterà, la mole di traffico attesa, i possibili bottleneck e via discorrendo.
Ma non vedo perchè un framework general-purpose, così come un cms “di massa” (Joomla, Drupal, Wordpress) non debba essere pensato per essere il più portabile possibile.
Ancora una volta credo che la verità assoluta non esista.
12
se parliamo di cms Drupal ad esempio è portatile sia su mysql che su postgres.
Io personalmente rispetto a postgres non considero neanche mysql un database
# - postato da sasuke - 05 Marzo 2010 - 20:28
13
Secondo me “in media virtues res” (o come si scrive ^_^)
Un approccio troppo basato sulle peculiarità del DB crea problemi di scalabilità, aggiornamento, cambiamenti e via dicendo.
Un approccio troppo indipendente va a scapito delle performance.
L’approccio ideale, IMVHO, è quello di fare delle scelte tecniche consapevoli fin dall’inizio e gestire il DB non come un bidone di dati ma neppure come lo strumento per far tutte le elaborazioni.