SQL o NOSQL ? Non è un problema...

Nell'ultimo decennio la moda del momento è quella dell'adozione di database NoSql, ovvero database schemaless che salvano e caricano entità stesse persistendole e caricandole al momento necessario. In realtà NOSQL è nato ancora prima di SQL. Ricordo che negli anni 90, quando SQL esisteva già ma era ancora utilizzato da sistemi IBM e DB2 e non da PC, il mio primo progetto software fu la prima regia pubblicitaria digitale italiana realizzata per una nota emittente radiofonica, nel quale adottai una tecnica di serializzazione dati all'interno di un file per strutturare le informazioni relative al singolo blocco pubblicitario. L'arcaico sistema utilizzava il nome del file per identificare la chiave di caricamento. Il file veniva poi deserializzato nella struttura usata per il blocco pubblicitario successivo e per preparare i singoli wav audio da lanciare.

Oggi, a distanza di quasi 30 anni e circa un centinaio di progetti software realizzati in svariati linguaggi, penso che non esistano tecniche di programmazione e tecnologie esclusive. Nel caso dei database appunto è possibile utilizzare entrambe le soluzioni per due momenti importanti nella realtà del nostro software: la registrazione del dato e la sua lettura. L'esempio pratico è quello di utilizzare il database NOSQL per memorizzare l'intera struttura dati di una registrazione per poi, mediante un sistema asincrono ad eventi, prelevare l'informazione e costruirne delle proiezioni in SQL utilizzate per la lettura e l'interrogazione. Questa tecnica (che può essere usata anche con il pattern CSQRS) permette di usare le peculiarità più importanti dei due mondi: lo schemaless di NOSQL e la velocità di interrogazione e aggregazione di SQL. I vantaggi comunque sono molteplici: il refactoring retroattivo delle strutture dati, la velocità di salvataggio indipendente dalla complessità strutturale dei dati di lettura, le performance di lettura di strutture dati denormalizzate realizzate a doc per la specifica interrogazione.