Dai diciamoci la verità: il software di oggi è un mondo che potresti definire “all-JSON”. E’ vero che alcuni sistemi legacy ad oggi risiedono su tecnologie diverse: avrai sentito parlare di SOAP, o di altro.

Ma a partire dalla sua nascita, il formato JSON (acronimo di Javascript Object Notation) ha guadagnato in fretta consensi. A causa della sua semplicità di integrazione e leggerezza, oggi lo potresti definire quasi uno standard “de-facto”.

Se anche tu gestisci sistemi informatici avrai a che fare con scambi dati in questo formato, e per esperienza, a volte, questo si scontra invece con la natura rigida e statica dei database relazionali.

La conseguenza è che mantenere e integrare sistemi così diversi può essere fonte di grandi mal di testa o di perversi sviluppi di codice per adattare un formato flessibile ad uno schema immutabile.

Addio flessibilità, addio manutenzione.

Leggi questo articolo e ti darò alcune idee per semplificarti la vita, avere un approccio più semplice e agile, e dormire più sereno.

Chi da sempre è abituato a strutture statiche e tipizzate può trovare difficile cambiare paradigma mentale. In fondo il formato JSON è un formato molto flessibile che idealmente può cambiare forma in qualsiasi momento.

Ricordo un progetto di mentoring per una società portuale che da sempre lavorava in RPG AS/400: un linguaggio molto rigido e macchinoso.

Quel progetto prevedeva l’insegnamento di tecnologie più moderne tra le quali l’utilizzo del formato JSON: l’opposto dell’approccio aziendale fino ad allora.

I pianti. I lamenti.

E lo stesso si potrebbe dire di chi ha a che fare con i database relazionali che, giustamente, hanno strutture fisse e tipi di dati statici.

JSON alla riscossa nei database relazionali

In alcuni casi però può essere necessario l’utilizzo di strumenti per trattare dati non in formato rigido: ovvero manipolare e trattare il formato JSON.

Ad esempio, potresti dover gestire procedure che sono soggette a cambiamenti nei parametri di input e non voler “cablare” in tutti gli strati di codice le nuove variabili.

Lo stesso vale per l’output che può assumere schemi diversi dovuti ai requisiti che cambiano sempre.

Ecco perché da relativamente poco tempo sistemi come SQLServer o PostgreSQL implementano funzioni e metodi per manipolare, leggere e trasformare il formato JSON.

Restituire i dati di una query in formato JSON

Per iniziare a capire perché sia una buona idea (o almeno da considerare) scambiare i dati in formato JSON facciamo il seguente esempio basato su SQL Server 2019 e il database di esempio WideWorldImporters.

Supponiamo di avere un’applicativo formato dal database, da un layer di backend e uno di frontend.

Il backend, anche se sviluppato in un linguaggio fortemente tipizzato (ad esempio Java o .NET) non fa altro che trasferire i dati dal database al frontend senza tenere conto di come sia fatto il modello dati ricevuto dal database.

Supponendo che in una prima versione si vogliano ottenere i dati di base di un cliente, il backend si potrebbe limitare ad invocare una stored procedure sul database il cui contenuto assomiglia al seguente.

SELECT [CustomerID]
      ,[CustomerName]
      ,[CreditLimit]
      ,[AccountOpenedDate]
      ,[WebsiteURL]
      ,[DeliveryAddressLine1]
FROM [WideWorldImporters].[Sales].[Customers]
WHERE CustomerID = @CustomerId
FOR JSON PATH

Come vedi in fondo c’è l’utilizzo della direttiva “FOR JSON PATH” che in pratica trasforma l’output in un oggetto JSON.

Se così non fosse, il risultato sarebbe un dataset tipizzato. Ma a quel punto il backend dovrebbe implementare un modello dati tale da supportare il dataset ritornato dal database e seguentemente serializzarlo in JSON prima di rispedirlo al frontend.

Immagina cosa potrebbe succedere se quel dataset cambiasse al cambiare dei requisiti di business: dovresti cambiare completamente il backend! Peccato che il valore aggiunto del backend (in questo caso) sia zero, perchè doveva fare solamente da passacarte…

E tu ti incupisci…

Con il risultato da SQLServer in JSON invece il risultato è il seguente:

[
    {
        "CustomerID": 581,
        "CustomerName": "Wingtip Toys (Munich, ND)",
        "AccountOpenedDate": "2013-01-01",
        "WebsiteURL": "http:\/\/www.wingtiptoys.com\/Munich",
        "DeliveryAddressLine1": "Shop 283"
    }
]

E’ chiaro che al mutare dei requisiti di business sarà immediato poter modificare la stored procedure ed in automatico il frontend si troverà l’oggetto JSON aggiornato e corretto.

Adesso non inizi ad interessarti all’argomento?

Eseguire il parsing di un oggetto JSON

Passiamo però alla necessità inversa ovvero leggere un oggetto JSON e renderlo utilizzabile da SQLServer.

Supponiamo di avere un oggetto JSON e volerlo utilizzare all’interno delle procedure T-SQL. SQL Server ci mette a disposizione la funzione “openjson” che ci permette di eseguire il parsing dell’oggetto come puoi vedere di seguito.

declare @json nvarchar(max);

set @json = N'
    {
        "CustomerID": 581,
        "CustomerName": "Wingtip Toys (Munich, ND)",
        "AccountOpenedDate": "2013-01-01",
        "WebsiteURL": "http:\/\/www.wingtiptoys.com\/Munich",
        "DeliveryAddressLine1": "Shop 283"
    }';

-- DATASET 1
select * from openjson(@json);

-- DATASET 2
select * from openjson(@json) with 
(
    [CustomerID] int,
    [CustomerName] varchar(max),
    [AccountOpenedDate] datetime,
    [WebsiteURL] varchar(max),
    [DeliveryAddressLine1] varchar(max)
);

Ed ecco i due risultati:

Risultato del parsing dell’oggetto JSON

Questione di approccio…

Questo è utile se ad esempio hai una procedura che debba prendere in ingresso un oggetto la cui struttura possa essere mutevole nel tempo.

Spesso le procedure vengono caricate di parametri di input sempre più numerosi con il risultato che sono più difficili da mantenere nel tempo.

E con l’effetto indesiderato spiegato prima: che devi ripubblicare anche il backend se non l’hai progettato per far fronte a questi scenari.

Ad esempio, una procedura che aggiorna un cliente potrebbe ricevere in input un solo oggetto JSON che ne rappresenti l’entità e non una variabile per ogni proprietà del cliente. Al variare delle proprietà del cliente dovrai solo aggiornare la tua procedura.

Nella realtà mi sono trovato a dover utilizzare questo approccio per un cliente. In quella situazione dovevo sviluppare un configuratore per manovellismi relativi agli infissi.

Ho voluto risolvere il problema realizzando una procedura che calcolasse l’elenco degli articoli che avrebbero dovuto comporre il sistema finale per un certo infisso.

Solo che le variabili di input del configuratore crescevano incontro dopo incontro.

Così ho cambiato approccio e introdotto una unica variabile che rappresentasse tramite JSON una classe dati derivante dal frontend. Il risultato finale è quello di ottenere un approccio di “boxing” tipico della programmazione ad oggetti in modo da non dover cambiare l’interfaccia ogni volta che cambiano i requisiti ma “inscatolando” i parametri in un unico contenitore.

Quel poco over head in più dovuto al parsing della stringa JSON mi ha fatto risparmiare non pochi grattacapi e tutto funziona alla perfezione.

Ottieni di più dal “post-relational” database

Questi sono solo alcuni esempi di utilizzo, ma come vedi è fondamentale sfruttare fino in fondo le potenzialità offerte anche dai database relazionali e non relegarli a meri sistemi di storage.

Con la tecnologia che richiede sistemi di scambio dati più snelli e duttili, devi assolutamente provare le nuove potenzialità offerte dai database attuali perché potrebbero semplificarti davvero il lavoro.

Una di queste è la capacità di gestire il formato JSON come un formato di prima classe per SQLServer (ma come ti ho detto altri sistemi non sono da meno, come PostgreSQL).

Ma non è l’unica.

In un secondo articolo ti farò vedere altro su questo argomento, perché le novità non finiscono certo qui.

Nel mio percorso ho raccolto molte informazioni interessanti in merito agli argomenti di cui ti ho parlato in questo articolo, ed ho scritto un libro “Why Your Data Matter”.

Essendo il frutto della mia passione ed esperienza diretta, ho scelto di mettere questo libro gratuitamente a disposizione di tutti gli IT Manager ed i CIO delle aziende che come te vogliono ottenere grandi risultati dalle loro scelte e dal loro lavoro (evitando di trovarsi in situazioni scomode e da risolvere con urgenza).

Ti invito a leggere le prime pagine scaricandole!
Se poi ti piacerà sarò felice di inviartene una copia GRATUITA direttamente nel tuo ufficio.  

Clicca qui per scaricare l’estratto del mio libro (se ti piacerà te lo invierò in formato cartaceo!) ==> il mio libro