Home > Quando utilizzare XML in un database?

Quando utilizzare XML in un database?

Bella domanda.

Visto che la CTP di Sql Server 2005 è finalmente feature complete, e che quindi è possibile cominciare a fare dello sviluppo "serio", è ora di cominciare anche ad aprire il vaso di Pandora delle nuove e contestate feature di Sql Server 2005. Una delle più interessanti è senza dubbio il nuovo tipo di dato xml.

Lasciando stare le risposte derivanti da fondamentalismi (passatemi il termine un pò forte ) circa convizioni più o meno religiose sullo uso di XML all’interno di un db, veniamo all’atto pratico: xml serve davvero? se si, in quali casi?

La prima risposta che dò a questa domanda è: NO, xml all’interno di un database normalmente non serve. C’è solo un caso che, ora come ora, mi viene in mente per giustificare (anzi, consigliare) l’uso di xml all’interno di un db. Diciamo quindi che nel 99.99% delle volte xml (come tipo di dato, intendo) può tranquillamente essere lasciato dove sta, ossia nel cassetto.

Il caso in cui vedo molto bene xml (sapendo e decidendo consciamente che sto andado palesemente a violare qualsivoglia regola di normalizzazione e quindi dovrò poi farne i conti a livello di codice) è relativo alla memorizzazione di dati strutturalmente diversi ma con la stessa logica di base.

In questo caso si devono memorizzare informazioni che hanno la stessa struttura ma che a priori non se ne conosce la quantità ed il tipo. Mi spiego meglio: supponiamo di dover memorizzare le informazioni per contattare i nostri clienti. Semplificando, possiamo immaginare di avere una tabella Clienti, una tabella Contatti ed una tabella di categorizzazione TipiContatti:

il campo Dettaglio deve contenere le informazioni per poter contattare il cliente. Ovviamente a seconda del tipo di contatto il modo e le informazioni per contattare il cliente cambiano.
Posso quindi pensare che in questo caso il tipo di dato xml possa essere di aiuto in quanto mi eviterà di dover creare o una colonna molto generica (per assurdo un sqlvariant) in modo da poter memorizzare indirizzi e-mail e cap all’interno della stessa, oppure mi aiuterà ad evitare di dover creare tante tabelle, una per ogni tipo di contatto, in modo da memorizzare in modo corretto le varie informazioni. Quest’ultimo approcio, benchè sia quello formalmente più corretto, è poco flessibile in quanto se un domani esce una nuovo tipo di contatto (es. Messenger), viene necessariamente richiesto l’intervento dello sviluppatore in modo da modificare e quindi creare una nuova tabella di supporto a questo nuovo tipo di contatto.

Un altro esempio molto più pratico lo si più facilmente immaginare applicando tale filosofia ad un sito eCommerce. Tipicamente le richieste di tali sistemi sono legate ad un forte semplificazione di sistemi di back-office: deve essere possibile da parte di chiunque (autorizzazioni permettendo) poter aggiungere prodotti con una maschera user-friedly e inoltre deve essere possibile aggiungere al volo nuove tipologie di prodotti.

Ovviamente ogni prodotto di diversa tipologia ha una differente scheda tecnica (un monitor al plasma avrà i pollici, il numero di pixel ecc ecc, mentre un rasoio od un orologio avranno ben altre caratteristiche tecniche) che in qualche modo deve essere memorizzata e sfruttata nella funziolità di ricerca (es: voglio cercare tutti i lettori mp3 che leggono anche i file .wma). Idealmente e semplicisticamente il database potrebbe essere fatto in questo modo:

In questo caso mi sembra assolumentate interessante sfruttare a fondo xml (visto anche che con Sql Server 2005 è possibile fare query sul documento xml) per memorizzare la scheda tecnica utilizzando tale formato.
Per la cronaca, e tanto per non fare solo accademia, tale soluzione è stata implementa utilizzando Sql Server 2000 (che fatica!) in un importante progetto, tuttora attivissimo con ottimi risultati.

In conclusione quindi, che dire? Che XML in database normalmente non serve, ma in casi molto sporadici può essere estramente utile per rendere molto flessibile un’applicazione, riducendo allo stesso tempo in modo notevole i tempi di sviluppo. Tutto questo, però, a patto che sia usato solo se effettivamente serve, altrimenti quanto appena detto non è più vero, ed, anzi, l’utilizzo diventa invece deleterio.

Avere il supporto xml in un database significa avere parecchia potenza tra le proprie mani…ma, parafrasando una nota pubblicità, direi che questa è nulla senza un’adeguata conoscenza dei pro e dei contro.

Chi è Davide Mauri

Microsoft Data Platform MVP dal 2007, Davide Mauri si occupa di Data Architecture e Big Data nel mondo dell'IoT. Attualmente ricopre il ruolo di "Director Software Development & Cloud Infrastructure" in Sensoria, societa specializzata nella creazione di Wearables e sensori per l'IoT applicati a tessuti ed oggetti sportivi.

Leggi Anche

Azure Key Vault e certificati code-signing: Strategie per la conformità post 1° Giugno 2023!

In questi giorni, ho avuto l’opportunità di esplorare il rinnovo di un certificato di code-signing …