Integrazione di SQL Server 2005 con il Common Language Runtime .NET

di Riccardo Golia, in Security & Admin,

Una delle più importanti innovazioni di SQL Server 2005 è l'integrazione col CLR (Common Language Runtime) del Framework .NET. L'integrazione col CLR permette a sviluppatori e database administrator di creare stored procedure, trigger, funzioni usando uno dei linguaggi del Framework .NET.

Un pensiero che ho avuto riflettendo sulla cosa è stato: "Ma anche nelle precedenti versioni di SQL Server era possibile creare procedure esterne, usando le extended stored procedure oppure utilizzando le stored procedure sp_oa per accedere a componenti COM... Non c'è nulla di nuovo quindi!" Poi però, una volta viste le caratteristiche della nuova versione, mi sono dovuto ricredere. Le extended stored procedure permettevano troppa libertà allo sviluppatore, l'integrazione col CLR invece limita tramite le permission il raggio di azione del codice managed.

Il vantaggio a favore del CLR rispetto alle extended stored procedure è il semplice fatto che non si è più obbligati ad utilizzare necessariamente C o C++ per svilupparle, ma è possibile spaziare e utilizzare tutti i linguaggi supportati dal Framework .NET. Questo fatto permette una certa flessibilità, una maggiore riusabilità del codice e l'uniformità del progetto di sviluppo, in quanto può essere utilizzato il medesimo linguaggio managed in ogni sua parte.

Rispetto all'utilizzo delle stored procedure sp_oa (sp_oacreate, sp_oadestroy, ecc.) che permettono l'accesso ai componenti COM tramite late binding, il codice managed è nettamente più performante e versatile. In ogni caso, se è proprio necessario utilizzare componenti COM, è possibile creare un wrapper ad-hoc, risolvendo il problema in modo elegante.

Passiamo a vedere i vantaggi dell'utilizzo del CLR.

Vantaggi

Semplificazione del modello di programmazione

T-SQL è pensato per la gestione e la manipolazione dei dati, ma non supporta l'utilizzo di tipi complessi quali array, collezioni, classi, ecc. Alcune operazioni possono venir simulate o ricreate tramite T-SQL, ma solo usando l'integrazione con il CLR è possibile utilizzare nativamente oggetti complessi.

Miglioramento della sicurezza

Il codice CLR viene memorizzato nell'engine di SQL Server 2005, utilizzando Code Access Security (CAS), garantendo una maggior sicurezza rispetto alla memorizzazione classica delle stored procedure.

Possibilità di definire tipi di dati e funzioni di aggregazione

User Defined Types (UDT) e User Defined Aggregates (UDA) permettono di espandere le capacità di SQL Server 2005.

Integrazione con Visual Studio

Lo sviluppo del database viene integrato nell'IDE di Visual Studio, questo permette agli sviluppatori di utilizzare un solo ambiente per lo sviluppo e il debug del database e dell'applicativo.

Migliori performance

Visto che il codice managed viene compilato in codice nativo prima dell'esecuzione, in molte situazioni possiamo ottenere migliori performance rispetto a T-SQL.

Elencati i vari punti a favore dell'utilizzo del CLR in SQL Server 2005, possiamo passare ad analizzare nel dettaglio un caso pratico.

Caso pratico

Con la possibilità di integrare codice managed all'interno di SQL Server 2005 possiamo finalmente risolvere il problema DATEPART per la restituzione della settimana. La funzione DATEPART nativa di T-SQL restituisce la settimana in base alle impostazioni americane, ovvero con domenica come primo giorno della settimana e con la prima settimana dell'anno che inizia il 1 gennaio. In Europa la notazione è diversa, dato che la prima settimana dell'anno è la prima settimana composta da 4 giorni e il primo giorno della settimana è il lunedì.

Usando T-SQL tradizionale, l'estrazione del numero della settimana non è un'operazione semplice e quasi sempre si preferisce delegare il compito lato applicativo, ad esempio, utilizzando la funzione DatePart di VBScript o di Visual Basic .NET.

Il codice T-SQL riportato di seguito restituisce il valore 47, mentre dovrebbe restituire il valore 46.

SELECT DATEPART(ww,'2005-11-18')

Risolviamo il problema creando un funzione utente (UDF: User Defined Function) che utilizza la funzione DatePart di Microsoft.VisualBasic.DateAndTime.

Partial Public Class SqlSample
    <Microsoft.SqlServer.Server.SqlFunction()> _
    Public Shared Function WeekOfTheYear(ByVal dateToEvaluate As DateTime) As Integer
        Return DatePart("ww", dDate, FirstDayOfWeek.Monday, FirstWeekOfYear.FirstFourDays)
    End Function
End Class

Una volta creata la classe, occorre compilarla. Per fare questo, da prompt di DOS eseguiamo il comando:

vbc /t:library /out:CLR2005.dll SqlSample.vb
2 pagine in totale: 1 2
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti