Il punto sul quale convergono la maggior parte delle osservazioni di Michael è il seguente: fino ad oggi l'utilizzo di un RDBMS è sempre stata la via più percorribile (mi sentirei quasi di asserire l'unica) per la maggior parte degli sviluppatori in quanto la quasi totalità  dei database manager systems di un certo calibro è strutturata su quel modello. Se però ci soffermiamo sui singoli ambiti di implementazione (OLAP, Data Mining, Web data collection, ...) appare abbastanza evidente che per ognuno di essi esiste almeno una soluzione più performante dei database relazionali.

àˆ quindi conseguenza di questa affermazione che, con l'andare del tempo, assisteremo ad un ridimensionamento nell'utilizzo dei database relazionali a favore di soluzioni sempre più verticali ed ottimizzate per il problema che stiamo cercando di risolvere.

Personalmente credo di condividere queste osservazioni anche a fronte del fatto che, da sviluppatore web quale sono, sto vivendo in prima persona l'avvicendarsi di un gran numero di database management system non relazionali (CouchDB in primis) che promettono prestazioni e scalabilità  fino ad oggi difficilmente ottenibili riuscendo inoltre ad rendere più facile la memorizzazione di alcune strutture tipiche del web.

Voi cosa ne pensate ? Stiamo assistendo alla fine di un'era o è soltanto un vento di passaggio ?

13 CommentiDi' la tua

Il tuo indirizzo email non sarà mostrato pubblicamente. I campi obbligatori sono contrassegnati da *

A tal proposito segnalo Redis, ad opera di un italiano molto in gamba!

kEsoNNo
kEsoNNo

Ne passerà  di tempo per un cambio epocale di questo calibro... ma nel frattempo tutti noi sviluppatori abbiamo la possibilità  di affiancare a soluzioni tradizionali anche database studiabili e adattabili ad hoc per la singola applicazione creata. Magari davvero la verità  sta nel mezzo, e soluzioni medio-piccole potrebbero beneficiare del boost di prestazioni garantito da soluzioni come CouchDb, e lasciare i database relazionali classici a soluzioni enterprise decisamente più complesse e onerose, soprattutto per la gestione e l'integrità  dei dati.

Luca
Luca

E' solo questione di tempo. Gli RDBMS hanno fatto il loro tempo ed il loro lavoro, ora é tempo di passare oltre.

lordmax
lordmax

Ma non stiamo esagerando? Quando vedrò un db non relazionale avere lo stesso successo di uno relazionale, se ne potrà  riparlare.

Ratamusa
Ratamusa

Google, Amazon ed altri giganti utilizzano già  database di questo tipo, anche se credo che la definizione di "object-oriented database" sia abbastanza generica. Queste implementazioni sono per la maggior parte delle enormi tabelle hash distribuite, comode in alcuni casi (come cache ad esempio per le ricerche di Google), ma inutilizzabili nella maggior parte dei casi come database in senso tradizionale. Uno dei punti di forza dei database relazionali é di riuscire a garantire già  a livello di DB l'integrità  dei dati. Gli "object-oriented database" (almeno quelli che conosco..) sono schema-free o comunque non implementano (come potrebbero?) gestioni equivalenti ad esempio alle foreign key. Ogni verifica ed operazione deve essere quindi implementata a livello dell'applicazione, con tutte le conseguenze che questo comporta. Quest'ultimo punto può essere una semplificazione per applicazioni medio-piccole ma sicuramente un problema per applicazioni di dimensioni maggiori. Una implementazione interessante da questo punto di vista é MongoDB, che implementa già  nel motore del database il supporto ad interrogazioni ed operazioni simili a quelle possibili con SQL. Personalmente ritengo queste tecnologie molto interessanti e per alcune applicazioni sicuramente gli OODB sostituiranno i database tradizionali, ma parlare di crepuscolo per questi ultimi mi sembra un po' eccessivo. Liberi di smentirmi. :)

Francesco Camarlinghi
Francesco Camarlinghi

Mi fa riflettere anche il fatto che Google App Engine abbia scelto un database non relazionale come, mi sembra, unica alternativa per chi decida di usufruire del loro servizio.

Sandro Paganotti
Sandro Paganotti

Sono uno sviluppatore web di conoscenze medio-ampie, e fino a questo post non avevo neanche mai sentito parlare di DB non-relazionali...

Slam
Slam

Non dimentichiamoci del ruolo che puo' avere RDF nei prossimi anni, puo' essere che molti dati si spostino su triplestore

Eugenio
Eugenio

…un DBMS relazionale che gestisce tutta la conoscenza attualmente esistente. :) e che é?!
Ovviamente si intende tutta la conoscenza relativa al dominio in cui tale base dati opera ;-)

Gianluca
Gianluca

Secondo me già  avviene nei fatti da tempo: se pensiamo alle tecniche di ORM/persistenza, esse hanno di fatto irrobustito le applicazioni enterprise da vari punti di vista (non solo nel creare una "visione a oggetti" dei dati, ma anche come dicevi nel rendere più semplice l'integrazione con data mining, machine learning, indicizzazioni, etc), ma hanno a mio avviso inevitabilmente contribuito a snellire via via progressivamente la necessità  di un uso sofisticato proprio della parte "relazionale" dei db. Oggi i vari Hibernate, piuttosto che le librerie per ORM di Zend Framework, per dire, consentono di compiere operazioni che nel peggiore dei casi ri-mappano relazioni già  esistenti sul db, e nel migliore possono persino sostituirle, a scapito di una spesa aggiuntiva di risorse. Di fatto io credo che avere in memoria strutture ad oggetti sia preferibile, e che il cambiamento sia già  sostanzialmente avvenuto. Il limite attuale, che frena la presa di coscienza da parte di sviluppatori, ricercatori e produttori, credo sia ancora nelle performance, e su questo punto condivido l'opinione di Gianluca. Ma sinceramente credo che sia un limite più che superabile, con le tecnologie attuali, e in più che sia anche amplificato dal non aver mai preso seriamente in considerazione la possibilità  di riprogettare ex-novo un sistema aggiornato alle necessità  attuali: non ci dimentichiamo che la teoria dei dbms relazionali pur essendo ottima (io come voi resterò a lungo legato ad essa, intendiamoci), si é affermata qualche decennio fa "vincendo" sulle altre, per questioni più tecniche che filosofico/teoriche... :-)

seralf
seralf