Dopo aver generato l'assembly CLR2005.dll, occorre inserirlo all'interno di SQL Server 2005 e quindi, tramite SQL Server Management Studio, eseguiamo le seguenti istruzioni:

Una volta che l'assembly è stato creato all'interno di SQL Server 2005, è possibile generare la funzione che richiama il codice managed che abbiamo visto in precedenza.

A questo punto non ci rimane altro che testare il funzionamento della funzione WeekOfTheYear che restituisce il valore 46 atteso.

Permission

Nell'esempio precedente abbiamo visto che alla creazione dell'assembly in SQL Server 2005 è stato necessario specificare il tipo di permission da applicare. Le possibili impostazioni sono:

• Safe: impostazione raccomandata in quanto permette l'accesso solo ai dati locali e a nient'altro;
• External_Access: oltre a permettere l'accesso ai dati, permette di accedere anche a file, rete, variabili di sistema e registro di configurazione;
• Unsafe: permette l'accesso indiscriminato alle risorse.

A livello di security l'impostazione consigliata è Safe in quanto il codice non può uscire dal contesto di SQL Server. External Access va utilizzato qualora sia necessario accedere a risorse esterne; l'assembly opera nel contesto dell'utente configurato nel servizio MSSQLServer. L'impostazione Unsafe a livello di contesto utente opera nello stesso modo dell'impostazione External Access, ma permette al processo MSSQLServer di eseguire operazioni che rischiano di comprometterne il funzionamento. Per questo motivo la modalità Unsafe va usata con attenzione.

Raccomandazioni

Di default l'integrazione con il CLR in SQL Server 2005 è disabilitata. Per attivarla è necessario richiamare la stored procedure sp_configure.

E' inoltre necessario ricordare che in fase di creazione di una funzione in T-SQL la sintassi da utilizzare è la seguente:

Nel caso di codice C# la sintassi è case sensitive, pertanto è necessario fare attenzione a scrivere [nome_classe] e [nome_funzione] correttamente.

Usare T-SQL o codice managed (CLR)?

Quando creiamo stored procedure, trigger, funzioni utente (UDF) possiamo decidere se utilizzare T-SQL oppure se utilizzare C# piuttosto che Visual Basic .NET o qualsiasi linguaggio supportato dal Framework .NET. Per tutte le operazioni di accesso ai dati con limitata logica procedurale è meglio utilizzare il buon vecchio T-SQL in quanto nettamente più performante. Per contro va usato codice managed per funzioni o procedure con una logica più complessa e che richiedono un grande impiego di CPU oppure nel caso sia necessario l'uso delle classi di base (BCL) del Framework .NET.

Un punto a favore dell'utilizzo del CLR è la possibilità di decidere se effettuare l'esecuzione lato server o lato client. Sia T-SQL che il codice managed possono risiedere sul server o sul client, ma solo il codice managed può venir eseguito nel computer client. Il codice T-SQL viene sempre eseguito solo ed unicamente lato server.

Non ha senso impiegare codice managed per costruire una stored procedure di inserimento dati o, peggio ancora, per eseguire una normalissima SELECT. Inoltre le nuove feature di T-SQL come, ad esempio, la possibilità di scrivere query ricorsive oppure le nuove funzioni di ranking (Rank e Row_number), permettono di risolvere molti problemi che in passato richiedevano molte righe di codice T-SQL. Pertanto in SQL Server 2005, prima di ricorrere all'integrazione con il CLR, è sempre opportuno considerare le eventuali alternative in T-SQL.

Conclusioni

L'integrazione col Common Language Runtime .NET da parte di SQL Server 2005 rappresenta senz'altro una delle più importanti innovazioni della nuova versione del DBMS targato Microsoft. Questa novità rappresenta un vantaggio oggettivo sia per gli amministratori di database sia per gli sviluppatori, ma va utilizzata con cognizione di causa e attenzione, come già sottolineato nell'articolo.

Contenuti dell'articolo

• Pagina 1
  • Vantaggi
  • Caso pratico
• Pagina 2
  • Permission
  • Raccomandazioni
  • Usare T-SQL o codice managed (CLR)?
  • Conclusioni