SQL e NoSQL a documenti: il confronto

6 marzo 2015

I database NoSQL rappresentano ormai una valida alternativa ai database relazionali. Capita sempre più spesso che le aziende scelgano soluzioni NoSQL come base dei propri progetti, sia per nuovi archivi che come approdo di un processo di migrazione.

Questo articolo mette a confronto i fondamenti della teoria relazionale con quelli dei DBMS NoSQL “a documenti”, anche tramite un semplice esempio che mostra gli accorgimenti necessari per convertire una database relazionale nella corrispondente versione NoSQL.

Quanto verrà illustrato può essere sperimentato, per la parte relazionale, su MySQL o altro DBMS di questa categoria, mentre per il NoSQL a documenti, la soluzione più diffusa al mondo è MongoDB.

DBMS relazionali e non: elementi a confronto

La conoscenza degli elementi di base di un database relazionale fa parte della cultura tecnica di buona parte degli sviluppatori ed amministratori di sistema. Riepilogando brevemente, tutto ruota attorno al concetto di tabella. Ne esisterà una per ogni tipo di informazione da trattare, ed ognuna sarà costituita da colonne, una per ogni aspetto dei dati.

Una tabella dovrebbe avere una o più colonne che svolgono il ruolo di chiave primaria, una sorta di indice che permette di riconoscere univocamente quella riga rispetto a tutte le altre. Tra le tabelle di un database relazionale, inoltre, possono esistere alcune relazioni. Una riga di una tabella A può fare riferimento ad un’altra riga di un’altra tabella B, e ciò può essere espresso inserendo la chiave primaria della riga di B tra i dati di quella di B.

Il linguaggio fondamentale usato per impartire comandi ad un DBMS relazionale è SQL ed una delle operazioni più comuni nonché più onerose in termini di risorse è il cosiddetto JOIN, un incrocio di tabelle in relazione tra loro che permette di offrire un set di dati unico con le informazioni complete.

Alla base di un database relazionale, c’è la progettazione della struttura interna, fatta di tabelle e relazioni. Questo lavoro concettuale iniziale condizionerà lo svolgimento di ogni operazione sui DB, dall’inserimento dei dati all’interrogazione, alla definizione dei JOIN.

La strutturazione rigida dei contenuti, tipica dei database relazionali fin qui descritti, è un elemento assente nei database NoSQL, e proprio tale assenza è uno degli aspetti che maggiormente ne hanno permesso il successo.

Le informazioni non troveranno più posto in righe elencate in tabelle, ma in oggetti completamente diversi e non necessariamente strutturati, come ad esempio documenti archiviati in collezioni. Su MongoDB, un database NoSQL basato sui documenti, il formato del documento è una delle caratteristiche più rilevanti. Si tratta di BSON (Binary JSON), una variante di JSON che include diversi tipi di dati.

Se, ad esempio, dovessimo inserire le informazioni di una persona (nome, cognome, età) in un database relazionale, creeremmo una tabella con tre colonne. In JSON, gli stessi dati verrebbero resi in un formato testuale come il seguente:

{"cognome":"Rossi","nome":"Carlo","eta":25}

Più oggetti JSON racchiusi tra parentesi quadre costituiscono invece una lista di oggetti.

Un oggetto JSON, complesso e articolato come vogliamo, rappresenta un documento da inserire nel database. Non esisteranno più tabelle, ma collezioni di documenti.

La chiave primaria del documento è un campo denominato _id che, se non viene fornito in fase di inserimento, verrà aggiunto automaticamente dal DBMS.

Nei DBMS NoSQL a documenti, è significativa l’assenza delle relazioni. I meccanismi con cui vengono collegate le informazioni sono infatti due:

  • Embedding: significa annidare un oggetto JSON all’interno di un altro. Questa tecnica sostituisce molto spesso le relazioni 1-a-1 e 1-a-molti. È tuttavia sconsigliabile utilizzarla quando i documenti (quello annidato e quello che lo contiene) crescono di dimensione in maniera sproporzionata tra loro, oppure se la frequenza di accesso ad uno dei due è molto minore di quella dell’altro;
  • Referencing: somiglia molto alle relazioni dei RDBMS, e consiste nel fare in modo che un documento contenga, tra i suoi dati, l’id di un altro documento. Molto utile per realizzare strutture complesse, relazioni molti-a-molti oppure casistiche non rientranti tra quelle consigliate per l’embedding al punto precedente.

Se vuoi aggiornamenti su SQL e NoSQL a documenti: il confronto inserisci la tua e-mail nel box qui sotto:
 
X
Se vuoi aggiornamenti su SQL e NoSQL a documenti: il confronto

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy