per ampliare la risposta sui db NoSQL alla domanda di
@koji82 in modo che sia comprensibile per tutti, ecco alcune spiegazioni.
Probabilmente chiunqie, in modo magari molto vago, sa che in un database i dati sono strutturati in tabelle e campi (righe e colonne).
In realta' non e' cosi'. Si prende per scontato che i db siano fatti cosi' ma questa tipologia di db e' una delle moltissime esistenti, e si chiamano db relazionali. Ne esistevano prima dei db relazionali (vedi db gerarchici) e e ne esistono molte altre tipologie (a oggetti, a grafo, a documenti, a chiave valore, ...)
Una delle caratteristiche fondamentali dei db relazionali (o spesso chiamati db sql, perche' il linguaggio con cui comunichi e' SQL, Structured Query Language) e'a appunto quello di strutturare i dati in modo molto rigido, con campi previsti a priori, tabelle con nomi ben definiti e
relazioni tra i campi/tabelle. le relazioni sono delle informazioni che legano varie tabelle tra loro, per evitare duplicazioni di dati. Se ho una informazione su un employee, non ho bisogno di duplicare i suoi dati anagrafici ogni volta che una tabella (stipendio, orari, assenza, ...) ne parla, ma uso una "relazione" verso quel employee.
Tutto cio' e' comodissimo, utilissimo, e gran parte del sw esistente e' basato su db sql. L'esistenza di relazioni permette inoltre di avere dati sempre consistenti (non e' possibile scrivere relazioni errate, cioe' dare un o stipendio a un employee non esistente, non e' possibile cancellare dati relazionati, cioe' non posso cancellare una persona se possiede un conto corrente).
Tuttavia il mondo oggi e' piu' complicato, molte applicazioni richiedono gestione di grandi quantita' di dati, la cui struttura spesso non e' nota a priori e non e' neppure prevedibile a priori. E in questo caso un db sql e' una gabbia in cui e' difficile muoversi.
I db NoSQL, tipo MongoDB, sono orientati alla gestione di collezioni di documenti, totalmente unstructured. Posso fare conto che qualunque campo sia scrivibile, a prescindere dalla struttura della collezione, perche' e' appunto libera, non esiste struttura.
La flessibilita' e' infinita, la comodita' e' elevatissima ma ... manca integrita' referenziale. E' possibile scrivere informazioni totalmente inconsistenti, posso avere uno stipendio che parla di un employee che non esiste.
Quindi sono db estremamente interessanti per moltissime applicazioni ma il loro uso spesso non e' adeguato, che so, in un sistema di accounting, in un sistema bancario, in uno shop, in un sistema di prenotazioni aeree, ... tutti sistemi in cui le relazioni sono core, e la flessibilita' della struttura e' secondaria.
Anche in questo caso, si possono scrivere molti libri, questa e' una descrizione super light dell'argomento, anche perche' i db a documenti (mongo) sono solo una delle categorie NoSQL, ve ne sono molte altre, con pro e contro.