Optare per un database SQL o NoSQL? Questa dicotomia rappresenta una delle più grandi “battaglie” informatiche di questi anni e del futuro prossimo.
Cominciamo con il dire che non esiste una soluzione unica a questo quesito e, come sempre nell’ingegneria, la risposta più corretta è sicuramente “dipende”. Questa parola fa infuriare i non tecnici proprio perché essendo non tecnici non possono comprendere in dettaglio le varie sfumature che portano a comprendere che “dipende” sia davvero la risposta esatta.
Proviamo a fare chiarezza.
SQL o NoSQL, le caratteristiche
Innanzitutto, per database SQL (Structured query language) si intende la famiglia più diffusa di database al mondo. Sono quelli relazionali per intenderci, con tabelle, righe, chiavi e, appunto, relazioni tra tabelle. Per descrivere i cittadini di un comune e le auto che possiedono serviranno due tabelle:
- Cittadini (con i vari campi come nome, cognome e codice fiscale – quest’ultimo, essendo univoco per definizione sarà nei casi di database ben progettati, la chiave della tabella)
- Automobili (con la targa, la descrizione ed un riferimento al proprietario, contenuto nell’altra tabella, “cittadini” come ad esempio il codice fiscale che è univoco ed in più chiave)
È immediato interrogare un database relazionale, quindi per sapere quante quali macchine ha “Mario Rossi” mi basta un comando di poche parole (SELECT …. FROM … WHERE …). Anche inserire, cancellare o modificare righe già esistenti è molto semplice in un database relazione.
Insomma, tecnologia datata ma con innumerevoli vantaggi.
SQL o NoSQL, i limiti dei DB SQL
Immaginiamo ora però di dover ricevere dati meteorologici da un numero elevato di fonti differenti e di dover poi, in un secondo tempo, organizzare i dati in un formato standardizzato.
In particolare, ogni fonte meteorologica avrà informazioni diverse come:
- Temperatura percepita
- Temperatura reale
- Vento
- Metri di visibilità
- Condizioni generali
- Umidità
- Giorno e ora di riferimento
Ogni fonte avrà solo una parte di queste informazioni e magari descritte con un numero diverso di campi, ad esempio per qualcuno la condizione generale di oggi sarà “soleggiato”, per un altro sarà “sole” – “livello 3”. Questi valori vanno resi coerenti per poter essere usati insieme allo stesso modo. Ci sono due soluzioni per questo:
- Mentre leggo la fonte la trasformo e la salvo direttamente in un database standardizzata (qui va bene un SQL)
- Voglio conservare i dati originali e quindi salvo le informazioni in un database NoSQL che permette flessibilità nella gestione di informazioni non strutturate
Va da sé che quando le fonti sono solo 2 con 2 tabelle SQL me la cavo, se però sono 20 e molto diverse per struttura e informazioni allora in quel caso bisogna considerare il salvataggio in un database NoSQL.
SQL o NoSQL, conclusioni
Quindi, come avrete capito, i database NoSQL consentono di salvare informazioni senza specificare a priori un modello dati e in più, in generale, soffrono di meno dei cugini SQL le grandi dimensioni. Insomma, se il DB è o diventerà grande, meglio un NoSQL. Ci sono dei trucchi come le tabelle in partizioni SQL per ovviare a problemi di lentezza, ma i database NoSQL nascono per gestire dati “Big”.
C’è un problema potenziale però con i database NoSQL
- Non è così facile interrogarli
- Non è così facile modificare i dati
Niente di impossibile si intende, ma dovete interrogare il DB in modo sempre diverso o modificare spesso dati, forse dovreste considerare comunque un database SQL.
Magari anche una soluzione ibrida, in cui si usa un NoSQL per salvare i dati non strutturati e successivamente un SQL per salvare i dati standard da interrogare e manipolare.
Come avete visto ci sono molti aspetti da considerare:
- I DB SQL sono più semplici da utilizzare, ma richiedono un grande vincolo che è quello di accettare dati in strutture “imballate”
- I DB NoSQL sono più complessi, ma permettono di gestire dati con strutture eterogenee e non note a priori ed in generale rendono bene per grandi moli di dati
In base alle esigenze specifiche dell’azienda sarà necessario valutare come sempre pro e contro, considerando che la soluzione perfetta non esiste, ma si può individuare il miglior compromesso in base ai dati a disposizione e alle attività che si devono compiere con questi.
