Database portability, un mito?

di Gianni Tomasicchio - 11 giugno 2008

E' realmente possibile e conveniente realizzare un'applicazione che possa utilizzare diversi database?

A guardare quanti database abstraction layer per PHP si trovano in giro (PDO, PEAR::MDB2, ADODb, ecc.) sembra quasi che non si possa fare a meno di scrivere codice indipendente dal database utilizzato. Le differenze tra i diversi database sono molte: costrutti SQL particolari, funzionalità proprietarie, tipi e formati di dati differenti, convenzioni diverse. Può un database abstraction layer colmare queste differenze? A quale prezzo?

Sicuramente le prestazioni sono destinate a degradarsi, sia perché viene inserito un ulteriore strato di codice tra l'applicativo ed il database, sia perché non avrebbe senso ottimizzare le query visto che questo procedimento dipende molto dal database utilizzato.

Inoltre non sarebbe possibile utilizzare alcune funzionalità proprietarie, come le ricerche full text di MySQL, che andrebbero sostituite con delle componenti software, sicuramente meno performanti. Ma a chi serve realmente la portabilità del codice rispetto al database utilizzato? Non è forse vero che la stragrande maggioranza delle applicazioni PHP usa MySQL? E se viene usato un altro database, perché si teme di doverlo cambiare in futuro? Non sarà mica un'esigenza commerciale piuttosto che tecnica?

Penso che i database abstraction layer siano più utili a realizzare delle API uniformi, indipendenti dal database utilizzato, ma dubito che possano garantire la database portability.

3 commenti

1 Marco Grazia Marco Grazia giovedě 12 giugno 2008, ore 09:34
Io penso che la portabilità di una funzione debba giustamente essere legata solo ai metodi di accesso, lo penso perché comunque le query vanno pur sempre ottimizzate caso per caso, credo che sia giusto che layer di astrazione come ad esempio la libreria PDO diano la possibilità al linguaggio e non all'applicazione che con esso costruisci, di essere portabile su tutta una serie di database in modo tale che si possa accedere a database diversi senza dover aggiungere altre funzioni specifiche per ogni database, come si faceva in passato.
C'è stato un momento in cui in PHP si aggiungevano funzioni su funzioni che nulla aggiungevano di particolare al linguaggio ma che allo stesso tempo ne aumentavano le difficoltà di manutenzione.
Con PDO che è una libreria che si può decidere se aggiungere oppure no in fase di compilazione del PHP, si è superata questa fase, almeno per i database.
Sta poi allo sviluppatore poter sviluppare applicazioni che tengono conto della portabilità o meno del codice, ma ovviamente le query di un database sono comunque sempre troppo legate al database stesso che si vuole utilizzare.

M.
2 Andrea Turso Andrea Turso venerdě 13 giugno 2008, ore 18:17
Sono d'accordo in toto con Gianni riguardo l'utilizzo dei Database Abstraction Layer (DAL) per mantenere disaccoppiati i diversi sottosistemi del software più che per astrarre il software dal dbms utilizzato. Questo perché non si presenta mai la necessità trasferire il database di un'applicazione (a regìme, quindi con un po' di dati al suo interno) da un dbms ad un altro, se non in qualche sporadico caso.
Quindi la database portability in php, come (credo) in molti altri linguaggi, è un'utopia perché i dbms hanno tutti caratteristiche differenti che rende impossibile raccogliere a fattor comune in un singolo sottosistema la gestione ottimale dei diversi dbms, a patto che non si utilizzi una libreria mastodontica con tutti i problemi che si porta dietro.
Quindi sfruttando l'occasione per dispensare una pillola sull'oop: se da un lato il disaccoppiamento rende il codice facilmente manutenibile e riutilizzabile, è anche vero che aggiunge maggiore complessità e tende a ridurre le prestazioni generali dell'applicazione, quindi l'aggiunta di nuovi livelli di astrazione va considerata con criterio. Ma come si capisce se è realmente necessario aggiungere un nuovo strato di software per garantire l'astrazione di un sottosistema?
Nel caso in cui l'area del codice sotto esame risulti essere instabile l'aggiunta di un nuovo livello di astrazione può rivelarsi la scelta migliore perché consentirà di modificare il sottosistema instabile in modo del tutto, o quasi, trasparente rispetto agli altri, riducendo così il tempo, i costi e la fatica necessaria a migliorare la codebase dell'applicazione.

Con instabile intendo dire sia instabile (nel senso letterario del termine) sia soggetto a frequenti modifiche e revisioni del codice.
3 Marco Grazia Marco Grazia venerdě 13 giugno 2008, ore 19:26
Io penso che se un'applicazione deve avere consistenza ci si deve per forza concentrare sui suoi metodi implementativi.
Il trasporto verso altre forme di database lascia sempre aperte delle incognite; mi rendo conto che la semplice idea di riscrivere un'applicazione non banale da capo è a dir poco ingestibile se non folle, ma è pur vero che se la strada per la sua ottimizzazione è la riscrittura completa, è pur vero che i tempi di trasporto da un server di database ad un altro non possono essere troppo lunghi e quindi la cosa va valutata in ogni suo passo in fase di progetto.
In quest'ottica credo che bisognerebbe sempre scegliere il futuro database su cui trasportare l'applicazione tenendo conto dei limiti che l'applicazione stessa incontrerebbe; per fare un esempio già affrontato da Gianni, penso che in fase di progetto bisogna saper accettare se conviene perdere un funzionalità come il caso delle ricerche full text di MySQL, piuttosto che scrivere un metodo che ne implementi la funzionalità o al limite evitare il porting, se il male minore è questo bisognerebbe comunque avere il coraggio di abbandonare il progetto di porting.
Ovvio il discorso va bene su modifiche a codice preesistente, come ho detto su non credo ad una API General Purpose e quindi non credo a progetti che promettono di fare di tutto.
Effettua l'accesso o registrati per inserire un commento