MongoDB ha la possibilità di avere i documenti che comprendono matrici di altri documenti. Questo risolve molti casi in cui si avrebbero relazioni in database funzionali.
Se una fattura ha più posizioni, non si metterebbe queste posizioni in una raccolta differenziata. Li avresti incorporati come array.
Mi chiedo degli esempi di vita reale su quando utilizzare NoSQL rispetto a quando no?
Ci sono molti diversi database NoSQL, ognuno progettato tenendo conto di diversi casi d'uso. Ma hai taggato questa domanda come MongoDB, quindi presumo che tu intenda in particolare MongoDB.
MongoDB presenta due vantaggi principali rispetto ai database relazionali.
Innanzitutto, ha una buona scalabilità.
Quando il database è troppo lento o troppo grande, è possibile aggiungere facilmente più server creando un cluster o un set di repliche di più frammenti. Questo non funziona quasi altrettanto bene con la maggior parte dei database relazionali.
In secondo luogo, consente dati eterogenei.
Immaginate, ad esempio, il database del prodotto di un negozio di computer. Quali proprietà hanno i prodotti? Tutti i prodotti hanno un prezzo e un venditore. Ma le CPU hanno una frequenza di clock, hard disk e chip RAM hanno una capacità (e queste capacità non sono paragonabili), i monitor hanno una risoluzione e così via. Come lo progetteresti in un database relazionale? Dovresti creare una tabella di valori di proprietà productID molto lunga oppure creare una tabella di prodotto molto ampia e sparsa con ogni proprietà che puoi immaginare, ma la maggior parte di essi è NULL per la maggior parte dei prodotti. Entrambe le soluzioni non sono davvero eleganti. Ma MongoDB può risolvere questo problema molto meglio perché consente a ciascun documento di una raccolta di avere un diverso insieme di proprietà.
Cosa non può fare?
Come una tecnologia piuttosto nuova, non c'è molta letteratura a riguardo. L'ecosistema software che lo circonda non è altrettanto efficace. Gli strumenti che puoi ottenere per i database relazionali sono spesso molto più brillanti.
Ci sono anche alcuni casi d'uso per cui MongoDB non è adatto.
- MongoDB non fa join. Quando i tuoi dati sono molto relazionali e denormalizzati, sarebbe controproducente, potrebbe essere una scelta sbagliata per il tuo prodotto. Ma potresti voler dare un'occhiata ai database di grafici come Neo4j, che si concentrano maggiormente sulle relazioni piuttosto che sui database relazionali. Aggiornamento 2016: MongoDB 3.2 ora ha un supporto JOIN rudimentale con lo $lookup aggregation stage, ma è ancora molto limitato nelle funzionalità rispetto ai database relazionali e grafici.
- MongoDB non esegue transazioni. Almeno transazioni non complesse. Alcune azioni che riguardano solo un singolo documento sono garantite come atomiche, ma non appena si influisce su più di un documento, non si può garantire che non avvengano altre query intermedie e si trovi uno stato incoerente.
- MongoDB non funziona per i report ad-hoc. Le sue opzioni per il data mining sono severamente limitate. Le funzioni di aggregazione piuttosto nuove aiutano e MapReduce può anche risolvere alcuni problemi sorprendentemente complessi quando si impara ad usarlo in modo intelligente, ma SQL ha solitamente gli strumenti migliori per cose del genere.
Con denormalizing i dati, si dovrebbe essere in grado di risolvere tutti gli stessi problemi che i database relazionali fare ... ma ci sono delle regole su come normalizzare i dati con i database relazionali. Esistono regole che è possibile utilizzare per aiutarli a denormalizzare i dati per utilizzare una soluzione NoSQL?
I database relazionali sono presenti da circa 40 anni. La loro teoria è un argomento ben studiato in informatica. Ci sono intere biblioteche di libri scritti sulla teoria dietro di loro. C'è una soluzione da libro per ogni caso d'angolo immaginabile ormai.
Ma i database NoSQL, d'altra parte, sono una tecnologia piuttosto nuova. Stiamo ancora cercando le migliori pratiche. Il consiglio più frequente è: "Usa la tua testa, pensa a quali query vengono eseguite più spesso e ottimizza i tuoi schemi di dati per loro".
Alcuni esempi su quando si potrebbe voler considerare l'utilizzo di una soluzione NoSQL in parallelo con un database relazionale?
Quando possibile vorrei consigliare di non usare due diverse tecnologie di database nello stesso prodotto:
- Chiunque mantiene e sostiene il prodotto deve avere familiarità con entrambe le tecnologie
- Risoluzione dei problemi diventa molto più difficile
- Gli amministratori di sistema devono mantenere un database aggiuntivo in esecuzione e aggiornato
- Hai un punto di errore aggiuntivo che può causare tempi di inattività
Raccomanderei solo di mescolare le tecnologie di database quando si soddisfano i requisiti senza che non diventi solo difficile ma fisicamente impossibile. Altrimenti, fai la tua scelta e rimani con essa.
NoSQL non è solo MongoDB. Esiste un sacco di nuove tecnologie di database raggruppate sotto l'etichetta con filosofie e casi d'uso completamente diversi e tutto ciò che hanno in comune sono cose che hanno anche in comune con i database SQL. – Philipp