Qualche volta, quando si parla di database, non si specifica la tecnologia di gestione dati a cui ci stiamo riferendo, perché si dà per scontato che si stia parlando di SQL. Questo perché in Italia è spesso diffusa una sorta di mentalità gestionale-centrica, che tende a rapportare la maggior parte dei concetti informatici al mondo del software ERP che ognuno ha in azienda. Software che, tipicamente, nel caso dei gestionali italiani orizzontali, si basa su un contenitore di dati popolato con tabelle e viste SQL.
Il SQL è infatti il prodotto dominante su alcune fasce di prodotti IT mentre in altri ambiti, come IoT o Big Data, sta venendo rapidamente sostituito da tecnologie che mirano a superarne i limiti. Questi limiti riguardano diversi aspetti, che possono interessare sia performance che gestione: i database SQL, infatti, si basano su strutture tabellari di dati, un modello che presenta certe rigidità quando si inizia a parlare di flessibilità e di scalabilità orizzontale.
L’alternativa NO SQL
Questi limiti hanno portato allo sviluppo di tecnologie di gestione dati alternative, i cosiddetti database No SQL, che non sono tabulari e gestiscono i dati in modo diverso rispetto alle tabelle relazionali. I database No SQL consentono di archiviare i dati strutturandoli in modo più vicino a come vengono pensati nelle applicazioni, risultando così più intuitivi anche alla lettura umana. Per recuperare un dato da un archivio No SQL è tipicamente necessaria una logica di ETL meno elaborata della sua controparte SQL, e ciò ne garantisce un beneficio a livello di performance.
Gli schemi dei database No SQL sono maggiormente amichevoli anche quando si tratta di implementare aggiornamenti a basso livello, che coinvolgono le definizioni dei tipi di dati. Questa caratteristica ha semplificato notevolmente la vita dei DB administrator, diventando una delle cause dell’adozione crescente da parte degli addetti del settore.
Con questi modelli è possibile gestire grandi quantità di dati, in modo semi strutturato o non strutturato, caratteristica che ha reso la soluzione No SQL la scelta prevalente per ambiti come l’IoT o i social media, dove la strutturazione del dato non necessita della rigidità formale di un ERP.
Esistono diversi tipi di database No SQL, che si distinguono a seconda di come gestiscono il dato: alcune tipologie molto diffuse sono quelle a coppie di valore-chiave (Key Value Store) oppure a documenti (Document database).
Key-Value store
Nella sua semplicità, l’idea alla base del database di tipo chiave-valore si è rivelata un’innovazione che ha permesso di implementare liste di dati indicizzabili e ricercabili in contesti in cui l’impiego del SQL sarebbe stato poco performante. Il modello chiave valore è un modello di gestione dati caratterizzato da un’estrema flessibilità, utilizzabile anche in contesti proibitivi per le esigenze di storage di un database relazionale: si pensi, ad esempio, ai mapping di Solidity, che consentono di gestire il salvataggio di dati semi strutturati su blockchain, contenendo i costi dell’interazione con Ethereum e offrendo throughput di scrittura e lettura ottimali.
Document database
Il limite dei Key-Value Store è la loro scarsa capacità di strutturare i dati. Per superare questo ostacolo sono stati progettati i database orientati ai documenti, ossia database che strutturano la coppia valore chiave in una lista di proprietà che permettono di scolpire meglio le diverse caratteristiche dell’informazione. Uno dei tipi più diffusi di database orientato ai documenti è la tecnologia MongoDB, che impiega per i record del database i file JSON. JSON (Java Script Object Notation) è un oggetto ampiamente diffuso nel mondo IT, grazie alla sua provenienza dal mondo Java Script, ed è in grado di memorizzare i dati in coppie campo-valore, dove i valori possono essere di diversi tipi e strutture, tra cui stringhe, numeri, date, matrici o oggetti. Un file JSON, però, non si limita ad ospitare una sola definizione di coppia campo-valore, ma ne può contenere infinite. Un campo-valore, a sua volta, può contenere non solo un singolo valore, ma un vettore di altre coppie campo valore o di strutture JSON, permettendo una nidificazione del dato preziosa in certi contesti.
Più flessibilità e integrazione con i web service
I documenti JSON possono essere raggruppati in raccolte, che archiviano documenti con contenuti simili. A differenza di una UNION SQL, non è necessario che tutti i documenti di una raccolta abbiano gli stessi campi, poiché i database JSON hanno una maggiore flessibilità, e non sono vincolati da uno schema rigido. Una volta definita una raccolta di oggetti JSON, è possibile indicizzarla ed eseguire ricerche e operazioni CRUD (Create, Read, Update, Delete). A differenza di SQL, dove queste operazioni vengono svolte invocando la sintassi SQL del fornitore del database (Microsoft od Oracle, ad esempio), i database di documenti eseguono le chiamate CRUD per mezzo di API (Application Programming Interface) fruibili con dei web service.
L’impiego di API è un aspetto rivoluzionario introdotto per la prima volta dai database No SQL, che rende più comodo agli sviluppatori impiegare i dati nelle loro app. Invece di dover dedicare tempo e risorse a scrivere codice wrapper per incapsulare nel flusso principale dell’applicazione le routine di accesso e gestione dei dati, con le chiamate API dei database No SQL è possibile invocare il web service velocemente, specificando parametri e operazione CRUD desiderata. L’adozione del JSON offre perciò tangibili benefici non solo a livello di gestione funzionale, ma anche dal punto di vista tecnico della semplicità di manutenzione e della leggibilità del codice.
