I database orientati ai documenti sono stati sviluppati per essere la prossima generazione di database e sostanzialmente sostituire completamente i database relazionali?
No. I database orientati ai documenti (come MongoDB) sono molto efficaci per il tipo di attività che vediamo tipicamente nei siti Web moderni (ricerche rapide di singoli elementi o piccoli insiemi di elementi).
Ma fanno dei grossi compromessi con i sistemi relazionali. Senza cose come la conformità ACID non saranno in grado di sostituire determinati RDBMS. E se guardi a sistemi come MongoDB, la mancanza di conformità ACID è un grande motivo per cui è così veloce.
È possibile che i progetti stiano meglio utilizzando sia un database orientato ai documenti che un database relazionale fianco a fianco per vari dati che si adattano meglio all'uno o all'altro?
Sì. In effetti, sto gestendo un sito Web di produzione molto grande che utilizza entrambi. Il sistema è stato avviato in MySQL, ma ne abbiamo migrato parte su MongoDB, b/c abbiamo bisogno di un archivio Key-Value e MySQL non è molto bravo a trovare un elemento in 150 milioni di record.
Se i database orientati ai documenti non sono destinati a sostituire i database relazionali, qualcuno ha un esempio di struttura di database che sarebbe assolutamente meglio in un database relazionale (o viceversa)?
Banca dati orientati ai documenti sono ottimi per la memorizzazione di dati facilmente contenuti in relazioni "valore-chiave" e relazioni "genitore-figlio" semplici e lineari. Semplici esempi qui sono cose come Blog e Wiki.
Tuttavia, database relazionali hanno ancora un forte vantaggio su cose come i rapporti, che tendono ad essere "basati sul set".
Onestamente, posso vedere un mondo in cui la maggior parte dei dati viene "gestita" da un database orientato ai documenti, ma in cui il reporting viene eseguito in un database relazionale che viene aggiornato dai lavori Map-reduce.
