Capitolo 1

Schema Dinamico


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

Schema Dinamico

Vedremo cosa si intende effettivamente con Schema Dinamico e i maggiori vantaggi che porta.

Senza schema, più precisamente a schema dinamico

Spesso si legge in giro che MongoDB è “schemaless”, letteralmente senza schema, ma in realtà non è proprio così.


Infatti ha un suo schema interno, praticamente è come un catalogo: una lista di database dove ogni database contiene le sue collections, ogni collection ha i suoi indici interni e contiene i suoi documenti.


In ogni documento se non è presente l’attributo _id viene implicitamente creato e ogni collection ha già un indice di ricerca proprio sull’_id. Volendo possiamo creare anche degli altri indici su altri attributi per velocizzare le nostre query. Ad esempio, ipotizziamo di avere una collection con molti documenti, lanciare una query su un attributo senza indice è poco performante perché bisogna accedere ad ogni singolo documento mentre, una query su un attributo con l’indice è molto più veloce perché è come effettuare una ricerca in una mini-collection formata solo dai valori del nostro attributo.


In aggiunta tutta la parte a schema dinamico offre enormi vantaggi: diversi documenti nella stessa collection possono avere differenti schemi supportando quindi il polimorfismo, che tra poco vedremo, inoltre possiamo avere una corrispondenza diretta tra i dati nella programmazione ad oggetti e il database. Questo facilita molto la programmazione e ovviamente le aziende possono adattarsi più velocemente ai cambiamenti, basti pensare a tutte le  metodologie come agile, scrum o extreme programming dove si rilasciano nuove release molto frequentemente.


Vediamo questi vantaggi nel lato pratico, quindi polimorfismo e corrispondenza dei dati tra programmazione ad oggetti e database.

I vantaggi di uno schema dinamico

Immaginiamo di avere una superclasse Forme nel nostro linguaggio preferito, abbiamo anche delle sottoclassi come Punto, Cerchio e Triangolo, ognuna con le sue caratteristiche.

Proviamo a pensare a come trasporre questa struttura in un database relazionale.

La soluzione più semplice ed immediata sarebbe quella di creare una tabella Forme e al suo interno mettere ad esempio le prime due forme, così però non consideriamo gli attributi delle sottoclassi.

Il primo è un punto quindi dobbiamo aggiungere x e y e dovremmo modificare la tabella per aggiungere le nuove colonne, stesso discorso per il raggio del Cerchio.

In questo modo la tabella può salvare correttamente gli attributi corretti sia per i Punti sia per il Cerchio però abbiamo dovuto modificare la tabella. Inoltre, le colonne aggiunte per il Punto rimangono vuote per il Cerchio e viceversa.

Non mi sembra un ottima soluzione. Un’altra potrebbe essere creare tabelle diverse per ogni sottoclasse ma diventa ancora più complicato, quindi meglio lasciar perdere...


Vediamo, invece, come risulta su Mongo.

Creiamo una nuova collection chiamata Forme e al suo interno creiamo un documento per salvare un oggetto di classe Punto, mettiamo quindi i suoi attributi x, y e salviamo, corrisponde perfettamente alla classe.

Possiamo aggiungere anche un altro documento nella stessa collection magari di classe Cerchio che quindi a differenza del punto avrà il raggio, anche qui abbiamo una corrispondenza diretta con la classe.

Insomma una soluzione ottima, facile e veloce.


Pensate a quelle situazioni in cui si richiedono tempi brevi per modifiche o aggiornamenti, lo schema dinamico è perfetto!

Ad esempio, se dopo il lancio del nostro nuovo e personalissimo social network ci accorgiamo di esserci dimenticati alcuni attributi degli utenti, ad esempio lo stato sentimentale, dobbiamo essere velocissimi a porre rimedio.

Non dobbiamo per forza fare una modifica enorme su tutti gli utenti già iscritti; ad esempio potremmo renderlo obbligatorio a tutti i nuovi iscritti, in questo modo chi si iscrive dopo la modifica avrà il campo.

Per chi invece si è iscritto prima, possiamo o lasciarlo facoltativo e aspettare che l’utente lo compili oppure potremmo anche inserirlo forzatamante dal database con un valore di default.

Insomma, siamo liberi di scegliere la soluzione migliore perché è il database che si adatta alle nostre esigenze.