Capitolo 1

Da Relazionale ai Documenti


Capitolo 1: Introduzione e Basi


Introduzione database no-SQL
Join, Transaction e Pre-Join
MongoDB in un'App
Come installare MongoDB
JSON e BSON
Schema Dinamico
Da Relazionale ai Documenti
Schema Design

Da Relazionale ai Documenti

Un esempio pratico di come passare da un database relazionale a una struttura in documenti su MongoDB.

Un blog in database relazionale

Fino ad ora abbiamo parlato di un sacco di cose interessanti ma per lo più erano teoriche, in questo video vedremo una cosa che per qualcuno può essere banale ma per me fu illuminante: la prova evidente della superiorità di Mongo. Vediamo un esempio più pratico che mai di come poter “convertire”, di come passare da una database relazionale ai documenti nel caso di un blog.


Non immaginiamoci un blog complicato con mille funzioni, ovviamente è un blog semplice ma sempre valido. Abbiamo sicuramente una tabella dei Post, quindi degli articoli, presumibilmente ogni articolo avrà il suo ID, il titolo, il testo, la data, e una chiave esterna per l’autore, molto comune. Avendo una chiave esterna per gli autori, abbiamo sicuramente un’altra tabella Autori con i dati che preferite, nome e password ad esempio.


Ok, articoli e autori, ogni blog che si rispetti deve dare la possibilità ai propri visitatori di commentare. Quindi, dobbiamo aggiungere una tabella per i commenti con la chiave esterna agli articoli, avremo il nome del visitatore, il corpo del commento e un’eventuale email, un sistema di commenti molto semplice.

Tra la tabella articoli e quella dei commenti c’è una relazione uno a molti, nello specifico un articolo può avere più commenti e un commento può appartenere ad un solo articolo.


Benissimo, se abbiamo tanti articoli ci serve qualcosa per organizzarli, magari un sistema di tag o categorie, quindi creiamo anche questa tabella con solo id e nome.

Le categorie però hanno una relazione con gli articoli di molti a molti, ovvero un articolo potrebbe appartenere a più categorie e una categoria può essere utilizzata da più articoli di conseguenza dobbiamo creare un’altra tabella che faccia da tramite per il collegamento e che quindi avrà sia l’ID del post sia quello del tag.


Benissimo, questo è come potrebbe essere il database relazionale di un blog molto semplice, adesso vi pongo una semplice domanda. Immaginiamo di aver già scritto anche il codice del blog nel vostro linguaggio preferito, quindi ci sarà un homepage, una pagina di dettaglio per il singolo articolo dove poter lasciare un commento e una pagina per ogni categoria. Benissimo, la mia domanda è questa: immaginiamo di voler leggere un singolo articolo, clicchiamo sul titolo e ci viene caricata la pagina ma, per poter mostrare questa pagina a quante tabelle bisogna accedere?


Provate a pensarci un attimo, immaginate la pagina davanti a voi e pensate a quali dati dovete mostrare, mettete pure in pausa il video per pensarci meglio.


Le avete contate?


Sicuramente dobbiamo mostrare titolo e testo dell’articolo quindi dobbiamo accedere alla tabella Articoli e siamo a 1, ovviamente dobbiamo scrivere il nome dell’autore e non il suo ID quindi dobbiamo accedere anche alla tabella Autori, e siamo a 2.

Alla fine dell’articolo mostriamo i commenti quindi accediamo ad un’altra tabella e siamo a 3.

Se fa parte di qualche categoria o se ha dei tag dobbiamo mostrarli, quindi non solo dobbiamo accedere a post-tag la tabella di collegamento ma anche alla reale tabella dei tag quindi siamo a 4 e 5.

Per mostrare la pagina di un singolo articolo abbiamo effettuato l’accesso a 5 tabelle.


Nulla di nuovo, questo è come funziona un blog in un database relazionale, per fortuna che ci siamo tenuti leggeri e avevamo poche “funzionalità” altrimenti avremo dovuto accedere a molte più tabelle.

Adesso vediamo come risulta su Mongo.

Un blog in documents

Dobbiamo creare sicuramente una collection per gli articoli. La struttura del documento potrebbe essere più o meno così: il titolo, il corpo dell’articolo, la data e un riferimento per l’autore.


Mancano però i commenti, cerchiamo di mettere in pratica la tecnica delle pre-join. Creiamo un array per i commenti, dove ogni commento non è altro che un documento con i suoi attributi: Nome del visitatore, corpo del commento e un’email; non ci servono chiavi esterne, sappiamo già che è riferito al nostro post perché è incapsulato al suo interno.


Ricordiamoci che l’array è una lista ordinata quindi i commenti hanno già un loro ordinamento.

Per i tags o categorie non c’è nulla di più semplice su Mongo, possiamo creare un altro array dove inseriamo i tags come stringhe, non ci serve un’altra collection, già così possiamo effettuare query per ogni singolo tag.


Ci sarà sicuramente un’altra collection per gli Autori però, questa volta, come id non usiamo un numero ma mettiamo direttamente l’username dell’utente, così facendo non abbiamo bisogno di frugare la collection per mostrare a video il nome, è già l’id.


Quindi, proviamo a ripensare alla domanda di prima questa volta usando Mongo, a quante collection accedo per mostrare la pagina di un singolo articolo? La risposta è solo 1!

Abbiamo già tutto quello che ci serve, ovviamente i dati dell’articolo, dell’autore ci basta l’username ed è già pronto, i commenti son tutti qui e anche i tags, tutto quello che ci serve in un solo documento.


Quando avevo visto questa lezione nel corso sull’university di MongoDB mi ero illuminato; cioè in un database con pochi dati e poche richieste al secondo ovviamente non percepiamo la differenza ma pensate di avere un blog molto seguito con tanti dati e con tante visite simultanee, nella migliore delle ipotesi accedo a 5 tabelle per ogni refresh!

Invece con Mongo basta un niente per eliminare i tempi di attesa per le joins e abbassare il carico del server. Un solo documento per avere tutto quello che ci serve, la struttura proposta è sicuramente già una buona soluzione ma potrebbe essere ancora molto ma molto più performante! Volete sapere con quale magica tecnica possiamo fare tutto questo? Sempre con le pre-join ma applicate con il giusto criterio.

Lo vediamo nella prossima puntata :D