È sbagliato pensare ai due sistemi in modo contrapposto, come se fosse una competizione e chiedersi se sia meglio NoSQL o SQL.
Le caratteristiche dei due modelli sono sostanzialmente diverse perché rispondono a esigenze diverse.
Infatti la domanda giusta è “meglio NoSql o SQL per quello specifico progetto?”.
Pensare a NoSql per un gestionale di una piccola azienda è come ammazzare una mosca con il cannone.
Dall’altra parte tentare di gestire un sistema di mappe e foto con un relazionale anche se tecnicamente possibile è pura follia.
Esistono casi in cui addirittura i due sistemi lavorano insieme. Anzi è fortemente consigliabile organizzare la parte di indicizzazione e gestione tramite un relazionale mentre i dati ingombranti risiedono su file system gestiti con altre tecniche.
In altre parole la domanda iniziale apre la strada ad una serie di domande.
Per esempio c’è la questione ACID e CAP; applicare a prescindere uno dei due paradigmi non ha senso.
‘ACID’ è l’acronimo di Atomicity, Consistency, Isolation, Durability (Atomicità, Consistenza (o coerenza), Isolamento e Durabilità).
‘CAP’ invece sta per Consistency, Availability, and Partition Tolerance (Consistenza, Disponibilità e Tolleranza di partizione).
Per intenderci: i database relazionali sono sviluppati secondo il paradigma ‘ACID’ mentre il NoSql, per la sua natura, segue il paradigma ‘CAP’.
Se il sistema che si intende sviluppare è un social network illimitato che, quindi, deve essere utilizzato in tutto il mondo con sistemi distribuiti, la priorità è la disponibilità (cosa importa se un utente perde la foto del suo gattino rispetto a milioni di utilizzatori che vogliono tutto e subito?).
Quindi CAP andrà benissimo; forse.
E mentre ACID funziona bene tutto nel suo insieme, cioè tutti i requisiti possono essere soddisfatti, secondo il ‘teorema CAP’ di Eric Brewer, le tre proprietà CAP non possono funzionare tutte insieme, cioè si possono ottenere soltanto combinazioni di due caratteristiche alla volta (CA, CP, AP); ma mai tutte e tre.
Ancora una scelta da fare che dipende dai casi.
Entrando poi nel merito del NoSql, anche se si decide a prescindere che è la soluzione migliore per tutto, poi che si fa? È meglio un grapho db o un document db, chiave/valore su disco o su RAM, colonna o …?
Ancora scelte da fare.
Se, invece, si vuole sviluppare un gestionale di una multinazionale che deve redigere bilanci precisi e certi e che quindi deve avere transazioni sicure, consistenti e affidabili, è ragionevole pensare alla stessa architettura per la soluzione? Salvo forzature, la risposta è no.
Come si fa, quindi, a decidere fra i due (tre, quattro …) modelli?
Tentare di affermare che uno è meglio dell’altro in assoluto è idiozia allo stato puro, ma il problema è che è proprio quello che succede in molti ambienti dove la cultura informatica è solo un incidente di percorso.
Non esiste il valore assoluto; ogni volta bisogna mettersi lì con pazienza e studiare la soluzione migliore.
Forse in cucina si può stabilire che esiste il vino perfetto per il certo piatto o lo strumento ideale per una certa preparazione, ma in informatica fare affermazioni del genere mostra solo il lato debole.
… e si rischia di non concludere alcunchè…