È ufficiale, Microsoft il prossimo anno rilascerà la nuova generazione di SQL Server chiamata in codice Yukon (anche se il nome ufficiale sarà SQL Server 2005). Il programma di testing già stato avviato e probabilmente già alla fine di quest'anno sarà possibile avere una versione beta del prodotto. Tutto fatto quindi, ma una domanda sorge spontanea: c'era veramente la necessità di introdurre una nuova versione di SQL Server? In effetti dopo tante ore passate con l'amato SQL Server 2000 la questione è più che leggittima.
Yukon, una vera rivoluzione.
Dobbiamo percepire l'arrivo di Yukon come una vera e propria rivoluzione nel
mondo dei software RDBMS, ma non solo. Nell'ottica Microsoft Yukon dovrebbe essere la piattaforma su cui si baseranno le prossime versioni di Active Directory (AD) ed Exchange.
Non si tratta quindi di una semplice release ma di una completa reingegnerizzazione del prodotto, difatti verranno introdotte più infrastrutture e tecnologie a supporto dei nuovi servizi che Yukon sarà in grado di offrire. Le nuove funzionalità sono talmente tante e numerose che una loro dettagliata meriterebbe ben più di un articolo, nonostante questo faremo una panoramica a quelle più rilevanti per il programmatore SQL Server:
- Potenziamento del linguaggio Transact SQL.
- Integrazione con il .NET Common Language Runtime (CLR)
- Supporto completo al mondo XML.
Il potenziamento del linguaggio Transact SQL
Nonostante il pieno supporto di Yukon al CLR di .NET (approfondiremo questo discorso nel prossimo articolo), il Transact SQL rimane lo strumento "principe" per lavorare con i set di risultati. Gli sviluppatori di Yukon hanno introdotto sia nuovi operatori che nuovi tipi di dati allo scopo di rendere il linguaggio T-SQL più efficace ed espressivo. Ecco una breve lista delle novità introdotte:
- Common Table Expressions (CTE)
- PIVOT (e UNPIVOT)
- Potenziamento dell'azione della clausola TOP
- Gestione degli errori nelle transazioni
- Nuovi tipi dati
Common Table Expressions
Possiamo paragonare una CTE a una sorta di vista non persistente. Vediamo la sintassi di una CTE:
With <nome della CTE>(<nomi delle colonne>)
As
(
<query>
)
Select * from <nome della CTE>
Un semplice esempio potrebbe essere:
With CTE_ClientiDiLondra
As
(
Select * From Customers Where City='London'
)
Select * From CTE_ClientiDiLondra
Come possiamo vedere una CTE è una tabella temporanea denominata che può essere utilizzata all'interno di query attraverso la clausola FROM. Una dimostrazione della potenza espressiva delle CTEs si ha nel loro utilizzo per la creazione di set di risultati gerarchici. Vediamo la sintassi tipo in questo caso:
With SimpleRecursive( field names)
As
(
<istruzione select per il membro non ricorsivo>
Union All
<Istruzione select per il membro ricorsivo>
)
Select * From SimpleRecursive
Un esempio più concreto potrebbe essere simile a questo:
WITH CTE_Category(catid, catname, cat_parentid, lvl)
AS
(
-- Membro non ricorsivo (AM)
SELECT catid, catname, cat_parentid, 0
FROM Category
WHERE catid = 1
UNION ALL
-- Membro ricorsivo (RM)
SELECT C.catid, C. catname, C. cat_parentid, M.lvl+1
FROM Category AS C
JOIN CTE_Category AS M
ON C. cat_parentid = M.catid
)
SELECT * FROM CTE_Category
Il corpo delle CTE contiene due query (chiamate in gergo membri), separate da un'istruzione UNION ALL. Il primo membro è quello non ricorsivo e viene invocato una sola volta da SQL Server. Il secondo membro invece è quello ricorsivo, fa riferimento al primo e viene invocato ripetutamente finché la query non ritorna un set di risultati vuoto. La concatezione dei risultati avviene tramite l'istruzione UNION ALL. Il numero di livelli di ricorsione può essere stabilito a priori dall'utente, altrimenti viene bloccato a 99.
PIVOT e UNPIVOT
In Yukon sono disponibili due nuovi operatori PIVOT e UNPIVOT. Entrambi modificano un'espressione con valori di una tabella di input e producono una tabella di output sotto forma di set di risultati. Sostanzialmente tramite PIVOT le righe della tabella sono trasformate in colonne, ed in aggiunta vengono eseguiti calcoli matematici e aggregazione dati. UNPIVOT esegue una operazione opposta, trasformando le colonne in righe.
L'operatore PIVOT è semplice da utilizzare; per prima cosa nell'istruzione SELECT specifichiamo i valori delle colonne della futura tabella pivot, poi nella clausola FROM definiamo la SELECT che restituisce i dati da cui vogliamo ottenere la tabella di output. Alla fine non rimane che applicare l'operatore PIVOT:
SELECT CustomerID, [1996] AS 'Y1996', [1997]
AS 'Y1997', [1998] AS 'Y1998'
FROM
(SELECT CustomerID,OD.UnitPrice * OD.Quantity - OD.Discount
AS TotalAmt,
Year(dbo.Orders.OrderDate) as OrdersYear
FROM dbo.Orders INNER JOIN dbo.[Order Details]
As OD
ON dbo.Orders.OrderID = OD.OrderID)
As Orders
PIVOT
(
SUM(TotalAmt)
FOR OrdersYear IN([1996], [1997], [1998])
) AS TabData
Order BY CustomerID
Questa query produrrà un risultato simile:
CustomerID Y1996 Y1997 Y1998
---------- ----------------------
ALFKI NULL 2293.25 2301.90002059937
ANATR 88.7999992370605 799.75 514.400001525879
ANTON 403.200012207031 6451.15002632141 660
AROUT 1379 6588.40002441406 5838.39996337891
BERGS 4324.40001296997 14532.249874115 8108.50009155273
Una query simile può esserci utile lavorando con report finanziari o statistici.
La clausola TOP
Nelle precedenti versioni di SQL Server la clausola TOP veniva utilizzata per limitare il numero di righe restituite da una SELECT. Il limite poteva essere espresso sia in modo assoluto (con un numero) che in modo relativo (in base ad una percentuale). Ecco alcuni esempi:
--Le prime 10 righe della tabella Orders
SELECT TOP 10 * FROM dbo.Orders
--Il 50% delle righe sul totale delle righe restituite, sul
--mio SQL Server sono 415 righe
SELECT TOP 50 PERCENT * FROM dbo.Orders
Ora in Yukon è possibile "parametrizzare" la clausola TOP, inoltre possiamo utilizzarla all'interno di istruzioni come INSERT, UPDATE e DELETE.
Create Procedure P_Select_Parametrizzata
@NumeroDiRighe int = 10
As
Select TOP (@NumeroDiRighe) * From Orders Order By OrderDate Desc
GO
Se eseguiamo la procedura memorizzata, passando il parametro @NumeroDiRighe valorizzato a 100 avremo come risultato l'elenco dei primi 100 ordini più recenti in base alla data di creazione dell'ordine.
Exec dbo.P_Select_Parametrizzata 100
Possiamo combinare in modo efficiente anche altre tipologie di query:
Select TOP (Select Count(*) from Employees) * From Orders
Gestione degli errori
Come per i linguaggi supportati dal framework .NET anche per Yukon sono stati introdotti i blocchi TRY..CATCH per gestione degli errori (eccezioni) durante le transazioni.
Il livello di sofisticazione è sicuramente minore rispetto al costrutto usato in .NET ma sicuramente più intuitivo del precedente RAISERROR (peraltro ancora supportato):
BEGIN TRY
sql statement
END TRY
...
BEGIN CATCH TRAN_ABORT
sql statement
END CATCH
Nuovi tipi di dati
In Yukon sono stati introdotti dei nuovi tipi dati, i principali sono:
- Tipo dati XML
- UtcDateTime
- Varchar(max), nvarchar(max) e varbinary(max)
Il tipo dati XML è sicuramente la maggiore novità introdotta in Yukon. Nel passato per salvare dati in formato XML su SQL Server lo sviluppatore era costretto ad utilizzare i tipi dati ntext/text o nvarchar/varchar a seconda delle dimensioni del documento XML.
Oggi invece esiste un tipo di dati appropriato che permette di memorizzare documenti o frammenti XML in formato nativo sui database SQL Server. Alla stregua degli altri tipi di dati anche con il tipo dati XML possono essere utilizzate le funzioni CAST e CONVERT, inoltre è possibile trasformare intere tabelle in frammenti XML:
DECLARE @xmlData AS XML
SET @xmlData = (SELECT * From Customers FOR XML AUTO, TYPE)
SELECT @xmlData
--produrrà come risultato un frammento XML
<Customers CustomerID="ALFKI"
CompanyName="Alfreds Futterkiste" ContactName="Maria Anders"
ContactTitle="Sales Representative" Address="Obere Str. 57"
City="Berlin" PostalCode="12209"
Country="Germany" Phone="030-0074321" Fax="030-0076545"/>
Le istanze di un tipo di dati XML possono appartenere a colonne di una tabella ma anche ad argomenti, a variabili di funzioni e procedure memorizzate. Il tipo di dati xml può inoltre essere specializzato indicando uno schema XML, il quale una volta abbinato ai dati XML fornisce un vincolo di convalida delle informazioni per i dati stessi.
Le operazioni su un'istanza del tipo di dati XML vengono eseguite tramite metodi di query XML disponibili in modo nativo in Yukon. Tali metodi accettano query e istruzioni di modifica dei dati appropriate per i dati XML. È quindi possibile specificare query (tramite il linguaggio XQuery) sui dati XML memorizzati nelle variabili o nelle colonne del tipo di dati xml e applicare gli aggiornamenti all'istanza XML stessa.
UtcDateTime è un tipo di dati per data e ora compatibile con i fusi orari. UtcDateTime verrà utilizzato nei database di transazioni di origine con operazioni globali.
Varchar(max), nvarchar(max) e varbinary(max), possono includere fino a 2 GB di dati e sono alternative utili dei tipi di dati text, ntext e image. Su questi possiamo operare con tutte le funzioni stringa supportate da SQL Server (esempio SUBSTRING) ed inoltre possiamo eseguire operazioni di UPDATE su porzioni di testo.
Abbiamo già accennato alle principali novità di SQL Server 2005 in tema di Transact SQL analizzando sia i nuovi operatori che i nuovi tipi di dati. Ora invece focalizzeremo l'attenzione sull'integrazione del mondo Xml all'interno di Yukon.
Il supporto all'XML in SQL Server 2000
Nelle precedenti versioni di SQL Server il supporto all'Xml veniva fornito in "modo esterno", tramite la tecnologia SQLXML e con l'aggiunta di estensioni ad alcune istruzioni Transact SQL (vedi clausola FOR XML). Grazie a queste era possibile convertire SELECT su tabelle del database in frammenti XML che una volta restituiti sul client potevano essere manipolati a proprio piacimento. Tutte queste tecnologie non erano però parte integrante di SQL Server, ma solo semplici aggiunte.
Il supporto all'XML in SQL Server 2005
Con Yukon il supporto all'Xml diventa parte integrante del motore di SQL Server. Nella nuova versione avremo quindi la possibilità di sfruttare sia la parte relazionale che quella non relazionale, ma soprattutto di godere della naturale integrazione di entrambe all'interno delle nuove applicazioni sviluppate con SQL Server 2005.
Ecco in breve le caratteristiche introdotte alfine di supportare l'integrazione con l'XML:
- Aggiunta del tipo dati XML (esaminato nell'articolo precedente).
- Supporto al linguaggio XQuery e XPath da parte del motore relazionale di SQL Server.
- Potenziamento della tecnologia SQLXML e delle estensioni XML del Transact SQL (vedi FOR XML e OPENXML).
- Aggiunta dell'XML Data Modification Language, un meccanismo che permette di modificare le istanze di dati XML memorizzati su SQL Server.
- Aggiunta dello strumento XQuery Designer.
Ovviamente in questo articolo non c'è spazio per trattare tutte le funzionalità elencate, ma avremo occasione di vedere come cambierà la progettazione delle applicazioni con SQL Server 2005.
Gestire i dati in formato XML
Con i "vecchi" database relazionali gestire i dati è piuttosto semplice e sicuro, basta usare i comandi SELECT, INSERT, UPDATE e DELETE del linguaggio SQL ed il gioco è fatto.
Ma con i nuovi dati di tipo XML come facciamo? Possiamo usare ancora le care istruzioni SQL? Certamente no! In SQL Server 2000 eravamo abituati a memorizzare l'Xml in campi di testo di lunghezza variabile in funzione delle esigenze, tipicamente (N)VARCHAR o (N)TEXT. In Yukon questo non è più necessario perché esiste un tipo dati apposito per l'Xml.
Il nuovo tipo dati XML
Possiamo pensare a questo nuovo tipo dati come alla classica tipologia dati già presente in SQL SERVER, ad esempio DATETIME, TEXT o FLOAT. Come questi può essere dichiarato e utilizzato nella definizione di colonne di tabelle, parametri di procedure memorizzare o funzioni definite dall'utente oppure variabili locali. Ma il tipo dati XML è in grado di fare ben altro:
- Memorizzare dati Xml in una forma forte (diciamo tipizzata). Possiamo legare alla nostra istanza di dati XML uno Schema Xml precedentemente registrato in Yukon.
- Memorizzare dati Xml in una forma debole(diciamo non tipizzata). Nessuno Schema Xml è legato all'istanza dati XML.
- Interrogare in modo diretto le istanze dati XML all'interno di istruzioni T-SQL o procedure memorizzate, tramite linguaggi appropriati quali XPath e XQuery.
- Aggiornare in modo diretto le istanze dati XML all'interno di istruzioni T-SQL o procedure memorizzate, attraverso l'utilizzo del nuovo XML Data Modification Language (XML DML).
- Creare indici e vincoli sulle colonne che contengono il tipo dati XML alfine di migliorare le performance e l'integrità dell' XML memorizzato al loro interno.
Come illustrato il nuovo tipo dati è potentissimo, e permette di gestire in modo completo l'XML all'interno di Yukon, sia la selezione che l'aggiornamento dei dati ed inoltre l'integrità ed i vincoli sui dati. Ora abbiamo un software RDBMS pronto a sfruttare appieno le potenzialità dell'XML.
Forma forte e forma debole.
Che differenza c'è tra forma debole e forma forte? Cominciamo col dire che Yukon salva tutte le istanze dati di tipo XML in forma debole, salvo altre opzioni. Difatti sappiamo che per produrre documenti o frammenti XML validi dobbiamo seguire delle regole ben precise.
La prima regola ci dice che l'XML deve essere "ben formato"; deve cioè aderire a regole di formattazione definite (tag aperti e chiusi, presenza di un elemento radice, ecc...).
Per definire un'istanza dati di XML in forma debole è sufficiente vedere questi esempi:
-- Creiamo una nuova variabile di tipo XML
DECLARE @xml xml -Ecco il nuovo tipo dato
-- Creiamo una tabella con una colonna di tipo XML
CREATE TABLE TabellaXML(ID int primary key,
ColonnaXML xml)
-- Creiamo una procedura memorizzata con un parametro di tipo XML
-- parameter
CREATE PROCEDURE ProcedureXML(ID int, @ParametroXML xml)
AS
...
-- Creiamo una tabella con una colonna di tipo XML
-- che abbia un valore di default predefinito
CREATE TABLE ProdottiComeXML (ID int primary key,
ProdottoComeXML xml default '<Prodotto></Prodotto>")
Oltre ad essere ben formato, un documento XML può avere vincoli più forti (definti dall'utente, da colui che crea il documento) che possono essere definiti e descritti all'interno di uno Schema Xml. Un'istanza di dati XML definita in forma forte DEVE quindi avere uno Schema XML associato al momento della sua definizione.
Gli Schema XML possono essere registrati in Yukon tramite la direttiva CREATE SCHEMA ed eliminati con DROP SCHEMA, vediamo un esempio:
--Creo uno schema per l'XML che definisce la struttura dati
--di un oggetto di tipo Prodotto che voglio utilizzare
--all'interno di una mia applicazione
CREATE XMLSCHEMA
'<?xml-version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace=
"https://www.html.it/Esempi/Yukon"
elementFormDefault="qualified"
xmlns="https://www.html.it/Esempi/Yukon"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:NS=" https://www.html.it/Esempi/Yukon ">
<xs:element name="Prodotto">
<xs:complexType>
<xs:attribute name="ProdottoID"
type="xs:integer"
use="required" />
<xs:attribute name="Nome"
type="xs:string"
use=" required " />
<xs:attribute name="Tipologia"
type="xs:string"
use="optional" />
</xs:complexType>
</xs:element>
</xs:schema>'
Una volta registrato lo Schema XML è accessibile tramite il "target namespace" https://www.html.it/Esempi/Yukon. Gli Schema Xml vengono memorizzati su una tabella di sistema apposita: sys.xml_namespaces. Ogni volta che salviamo uno Schema XML Yukon non si limita a memorizzarlo come semplice testo nelle tabelle di sistema preposte, ma effettua un "parsing" dello Schema Xml estrapolando tutti i tipi dati trovati. Successivamente questi dati verranno importati e registrati all'interno dei metadati di sistema di Yukon. Ovviamente Yukon possiede una funzione per ricreare i metadati di uno Schema XML precedentemente utilizzato (questo nel caso di modifiche apportate in seguito):
SELECT xml_schema_namespace ('https://www.html.it/Esempi/Yukon')
Ora possiamo rispondere con merito alla domanda iniziale sulla differenza tra forma debole e forma forte. Inanzitutto vediamo come associare lo Schema XML appena registrato sulla colonna di una tabella:
--A differenza del precedente esempio, la colonna ProdottoComeXML
--viene abbinata a uno Schema XML tramite il target namespace
--'https://www.html.it/Esempi/Yukon
CREATE TABLE ProdottiComeXML
(
ID int primary key,
ProdottoComeXML xml ('https://www.html.it/Esempi/Yukon')
)
Ora all'interno della colonna ProdottoComeXML possiamo inserire SOLAMENTE dati XML che sia conformi alle regole define nello Schema Xml con target namespace "https://www.html.it/Esempi/Yukon".
--Inserimento valido
INSERT INTO ProdottiComeXML (ID, ProdottoComeXML)
VALUES
(
10,
CAST('
<Prodotto xmlns="https://www.html.it/Esempi/Yukon"
ProdottoID="10"
Nome="Caffè Espresso" Tipologia="Caffè">
</ Prodotto >'
AS xml)
)
--Inserimento NON VALIDO l'attributo ProdottoID
--deve avere un valore NUMERICO INTERO
INSERT INTO ProdottiComeXML (ID, ProdottoComeXML)
VALUES
(
20,
CONVERT(xml,'
<Prodotto xmlns="https://www.html.it/Esempi/Yukon"
ProdottoID="10X"
Nome="Prosciutto Superiore" Tipologia="Alimentari">
</ Prodotto >')
)
Per eliminare uno Schema XML è sufficente usare l'istruzione DROP SCHEMA ricordandoci di eliminare prima di questa azioni gli oggetti a cui lo schema fa riferimento (le colonne o i parametri delle procedure in cui è referenziato)
DROP XMLSCHEMA NAMESPACE 'https://www.html.it/Esempi/Yukon'
Con Yukon possiamo convertire in modo implicito od esplicito stringhe di testo in dati XML grazie alle funzioni CAST e CONVERT di T-SQL. Inoltre tramite l'operatore OPENROWSET possiamo fare caricamenti massivi di dati in formato XML.
Creare vincoli su dati XML
Oltre a registrare degli Schema XML, per rafforzare l'integrità dei dati XML possiamo anche affidarci ai vincoli a livello di tabella:
--Creiamo la tabella con un vincolo check sulla colonna
CREATE TABLE ProdottiComeXML
(
ID int primary key,
ProdottoComeXML xml (check(ProdottoComeXML::exist('/Prodotto/@ProdottoID'
= 1)
)
--Tutto OK qui...
INSERT INTO ProdottiComeXML (ID, ProdottoComeXML)
VALUES (1, '<Prodotto ProdottoID="1" />')
--Qui SQL Server restituisce un errore, manca l'attributo ProdottoID
INSERT INTO ProdottiComeXML (ID, ProdottoComeXML)
VALUES (2, '<Prodotto></Prodotto>')
Tramite il metodo exist() del nuovo tipo dati XML possiamo eseguire un controllo sull'esistenza o meno dell'attributo ProdottoID nei frammenti XML che verranno inseriti nella colonna ProdottoComeXML. Il vincolo è formalizzato attraverso una query XPath.
Abbiamo visto come Yukon supporti in modo nativo l'XML. Questa sua peculiarità gli garantisce la possibilità di gestire i dati attraverso due modelli:
- Dato-Centrico, tipico del modello relazionale (le informazioni sono rigidamente organizzate in tabelle costituite da righe e colonne).
- Documento-Centrico, tipico dell'XML (le informazioni sono liberamente organizzate in modo gerarchico, gli elementi collegati sono tra loro annidati e vanno a costruire una struttura ad albero).
Ciò significa integrare il meglio dei due mondi: da una parte la flessibilità del modello XML e dall'altra le grandi performance del modello relazionale.
Oltre a memorizzare in modo nativo documenti XML Yukon ci offre la possibilità di aggiornarli ed interrogarli tramite linguaggi specifici come XML DML e standard de facto come XPath e XQuery.
I metodi del tipo dati XML
Il tipo dati XML è molto differente dai classici tipi dati esistenti in SQL Server (float, money, ecc.), difatti offre dei metodi che aiutano l'utente nella modifica e nella interrogazione di istanze dati di tipo XML. Tutti questi metodi si servono del linguaggio XQuery per eseguire i propri compiti, vediamo i 4 metodi supportati:
- value(), restituisce un tipo dati nativo di SQL Server (float, nvarchar, datetime, ecc...) partendo dal tipo dati XML.
- query(), restituisce un frammento XML in forma debole partendo dal tipo dati XML.
- exist(), possiamo verificare o meno l'esistenza di un nodo o valore all'interno di una istanza di dati tipo XML.
- update(): possiamo aggiornare le istanze dati di tipo XML tramite l'utilizzo del linguaggio XML Data Modification Language (XML DML)
L'XML DML è un'estensione del linguaggio XQuery nato per supportare l'aggiornamento dei dati di tipo XML in Yukon. Questo linguaggio si formalizza attraverso l'uso di tre parole chiave:
- insert: inserisce un nuovo nodo, valore o attributo all'interno di un'istanza dati di tipo XML
- update: aggiorna un nodo, valore o attributo esistente in un'istanza dati di tipo XML
- delete: elimina un nodo, valore o attributo esistente da un'istanza dati di tipo XML
Passiamo ora a vedere qualche esempio.
XQuery
I documenti XML hanno per definizione una struttura gerarchica, in cui gli elementi sono tra loro annidati; pensiamo ad un documento XML che identifichi un ordine all'interno di un sistema di commercio elettronico di un sito web:
<Ordine Id="12">
<LineaOrdine>
<NomeProdotto>Computer Portatile</NomeProdotto>
<CategoriaProdotto>Laptop</CategoriaProdotto>
<PrezzoInEuro>1000</PrezzoInEuro>
<ScontoInEuro>10</ScontoInEuro>
<QuantitaProdotto>1</QuantitaProdotto>
</LineaOrdine>
<LineaOrdine>
<NomeProdotto>Mouse USB</NomeProdotto>
<CategoriaProdotto>Mouse</CategoriaProdotto>
<CategoriaProdotto>Accessori PC</CategoriaProdotto>
<PrezzoInEuro>10</PrezzoInEuro>
<ScontoInEuro>1</ScontoInEuro>
<QuantitaProdotto>2</QuantitaProdotto>
</LineaOrdine>
</Ordine>
L'elemento ordine contiene una o più linee d'ordine in base al numero di prodotti acquistati. A sua volta ogni linea contiene tutte le informazioni utili ad evadere l'ordine da parte del sistema di ecommerce del sito, nome del prodotto, categoria, prezzo, sconto applicato, quantità ecc.
Recuperare informazioni da questo documento XML con SQL Server 2000 non è possibile, se non utilizzando l'estensione OPENXML di T-SQL.
Con Yukon invece, grazie al linguaggio XQuery, navigare nelle strutture ad albero dei documenti XML diventa molto semplice. Il linguaggio XQuery ha una sintassi simile ad XPath, ed è per questo molto intuitivo ma anche più efficace.
Difatti è possibile creare nuovi documenti XML partendo da parti di altri documenti XML esistenti; tutto questo è realizzabile tramite una semplice query.
Ricordiamoci che ogni istruzione XQuery può essere eseguita direttamente all'interno di codice T-SQL.
Usare il metodo query()
Con XQuery possiamo interrogare e creare documenti XML, ecco un semplice esempio:
--1. Creo una variabile di tipo XML che conterrà l'ordine in formato XML
DECLARE @ordineXML xml -Uso il tipo dati XML
SET @ordineXML = '<Ordine Id="12"><LineaOrdine>...</LineaOrdine></Ordine>'
--2. Interrogo il documento XML tramite il metodo query()
SELECT @ ordineXML::query('/Ordine/LineaOrdine/NomeProdotto')
-- Risultato atteso dalla query
<NomeProdotto>Computer Portatile</NomeProdotto>
<NomeProdotto>Mouse USB</NomeProdotto>
--3. Proviamo a creare un nuovo documento XML che contenga
-- solamente i prodotti più costosi nell'ordine:
SELECT @ordineXML::query('
FOR $prodottoCostoso IN
/Ordine/LineaOrdine[PrezzoInEuro>500]/NomeProdotto
RETURN <NomeProdottoCostoso>{data($prodottoCostoso)}</NomeProdottoCostoso
>')
-- Risultato atteso dalla query
<NomeProdottoCostoso>Computer Portatile</NomeProdottoCostoso>
<NomeProdottoCostoso>Mouse USB</NomeProdottoCostoso >
L'ultima query è interessante:
- L'istruzione FOR legge tutti i nomi dei prodotti con un prezzo maggiore di 500 Euro.
- Tutti i nomi trovati vengono assegnati ad un nuovo elemento denominato NomeProdottoCostoso.
- Con l'istruzioni RETURN viene restituito il nuovo documento XML
In questo caso abbiamo creato un frammento XML partendo da un documento XML esistente.
Il metodo query() inoltre può essere usato su colonne, variabili T-SQL e parametri di procedure memorizzate a patto che appartengano al tipo dati XML. Oltre al metodo query() abbiamo anche i metodi value() ed exist().
--Per recuperare il valore scalare da un nodo:
SELECT @ordineXML::value('/Ordine/LineaOrdine/CategoriaProdotto,'string') AS Categoria
--Lo stesso ma da una tabella con una colonna appartenete al tipo dati XML
SELECT ordineID, ordineXMLInColonna::value('/Ordine/LineaOrdine/NomeProdotto',
'varchar(50)') AS Nome
FROM OrdiniXmlInTabella
Il metodo exists() restituisce il valore 1 quando il nodo esiste ed il valore 0 se il nodo non esiste.
--Per verificare l'esistenza del nodo ScontoInEuro
SELECT @ordineXML::exist('/Ordine/LineaOrdine/ScontoInEuro')
XML Data Modification Language (XML DML)
Finora abbiamo visto come sia possibile interrogare e creare documenti XML tramite il linguaggio XQuery ma non abbiamo accennato a come sia possibile alterare il contenuto di un'istanza dati di tipo XML.
Con SQL Server 2000 è impossibile modificare XML in modo nativo, per forza si deve passare per componenti client (ASP, VB, .NET, ecc.) in grado di farlo, con Yukon no.
Allo scopo Microsoft ha creato un'estensione al linguaggio XQuery, denominata XML Data Modification Language, viene utilizzata attraverso il metodo modify() del tipo dati XML.
XML DML usa tre parole chiave insert, update e delete, del tutto identiche a quelle del T-SQL, vediamo un esempio:
UPDATE OrdiniXmlInTabella
SET ordineXMLInColonna::modify('update Ordine/LineaOrdine[1]/NomeProdotto/text()
to "Nome del nuovo prodotto"')
WHERE ordineID = 100
Nell'esempio abbiamo modificato il nome di un prodotto presente nell'ordine numero 100, XML DML è piuttosto semplice ed intuitivo e molto simile alle già note istruzioni Transact SQL. L'unica differenza è che l'uso di update() in XML DML non cambia l'intero contenuto della colonna di tipo XML ma solamente la porzioni di dati interessati, un nodo, un attributo, un valore (come nel nostro caso). Allo stesso modo possiamo usare sia delete() che insert().
DECLARE @XML xml
SET @XML = '<Ordine><LineaOrdine><NomeProdotto>Computer Portatile</NomeProdotto></Ordine>'
SET @XML:modify('insert <CategoriaProdotto>Laptop</CategoriaProdotto> into /Ordine/LineaOrdine')
Conclusione
Questo articolo su Yukon è stato una panoramica dei macroconcetti che saranno (potrebbero esserci modifiche al momento del rilascio ufficiale) alla base delle future applicazioni Internet basate sull'integrazione del mondo XML e del mondo relazionale dei database. Se tutto continuerà in questa direzione l'arrivo di Yukon segnerà una svolta epocale nel mondo dei software RDBMS. Non ci resta che attendere fiduciosi!
