Panoramica dell'integrazione con CLR
Common Language Runtime (CLR) rappresenta il fulcro di Microsoft .NET Framework e fornisce l'ambiente di esecuzione per tutto il codice .NET Framework. Il codice eseguito in CLR viene chiamato codice gestito. CLR fornisce varie funzioni e servizi necessari per l'esecuzione del programma, incluse le funzioni di compilazione JIT (Just-In-Time), di allocazione e gestione della memoria, di imposizione dell'indipendenza dai tipi, di gestione delle eccezioni, di gestione dei thread e di protezione. Per ulteriori informazioni, vedere .NET Framework SDK.
Grazie all'integrazione di CLR in Microsoft SQL Server, è possibile creare stored procedure, trigger, funzioni definite dall'utente, tipi definiti dall'utente e aggregazioni definite dall'utente nel codice gestito. Poiché il codice gestito viene compilato nel codice nativo prima dell'esecuzione, è possibile ottenere notevoli miglioramenti delle prestazioni in alcuni scenari.
Nel codice gestito viene utilizzata la protezione dall'accesso di codice (CAS, Code Access Security) per impedire che gli assembly eseguano determinate operazioni. In SQL Server tale protezione viene utilizzata per proteggere il codice gestito ed evitare di compromettere il sistema operativo o il server di database.
Vantaggi dell'integrazione con CLR
Transact-SQL è progettato in maniera specifica per l'accesso e la modifica diretta dei dati nel database. Sebbene Transact-SQL risulti particolarmente vantaggioso per l'accesso e la gestione dei dati, non rappresenta un linguaggio di programmazione completo. Transact-SQL non supporta, ad esempio, matrici, raccolte, cicli foreach, scorrimento bit o classi. Il codice gestito dispone di supporto integrato per questi costrutti, sebbene sia possibile simularne alcuni in Transact-SQL. A seconda dello scenario, l'implementazione di determinate funzionalità del database nel codice gestito può risultare particolarmente vantaggiosa.
Microsoft Visual Basic .NET e Microsoft Visual C# offrono funzionalità orientate a oggetti quali incapsulamento, ereditarietà e polimorfismo. Il codice correlato può ora essere organizzato facilmente in classi e spazi dei nomi. In questo modo è possibile organizzare e gestire il codice più facilmente quando si utilizzano grandi quantità di codice server.
Il codice gestito risulta più appropriato di Transact-SQL per i calcoli e la logica di esecuzione complicata. Dispone inoltre di un supporto esteso per molte attività complesse, inclusa la gestione delle stringhe e le espressioni regolari. Grazie alle funzionalità della libreria .NET Framework, è possibile accedere facilmente a migliaia di classi e routine preesistenti da qualsiasi stored procedure, trigger o funzione definita dall'utente. La libreria di classi di base (BCL, Base Class Library) include classi che forniscono funzionalità per la modifica delle stringhe, operazioni matematiche avanzate, accesso ai file, crittografia e altro ancora.
[!NOTA]
Sebbene molte di queste classi siano disponibili nel codice CLR in SQL Server, quelle che non sono appropriate per l'utilizzo sul lato server, ad esempio le classi di windowing, non risultano disponibili. Per ulteriori informazioni, vedere Librerie .NET Framework supportate.
Uno dei vantaggi del codice gestito è l'indipendenza dai tipi o la garanzia che il codice acceda ai tipi solo con modalità consentite e ben definite. Prima che venga eseguito il codice gestito, CLR verifica che il codice sia sicuro. Viene ad esempio eseguito un controllo del codice per verificare che non venga letta memoria che non sia stata scritta in precedenza. CLR è inoltre in grado di garantire che il codice non modifichi la memoria non gestita.
L'integrazione con CLR offre un potenziale miglioramento delle prestazioni. Per ulteriori informazioni, vedere Prestazioni dell'integrazione con CLR.
Scelta tra Transact-SQL e codice gestito
Quando si scrivono stored procedure, trigger e funzioni definite dall'utente, è necessario decidere se utilizzare il linguaggio Transact-SQL tradizionale o un linguaggio .NET Framework quale Visual Basic .NET o Visual C#. Utilizzare Transact-SQL quando il codice eseguirà soprattutto l'accesso ai dati con una logica procedurale ridotta o nulla. Utilizzare codice gestito per le procedure e le funzioni che richiedono un utilizzo elevato della CPU e sono caratterizzate da una logica complessa o quando si desidera utilizzare la libreria di classi di base di .NET Framework.
Scelta tra l'esecuzione nel server e nel client
Un altro aspetto che incide sulla decisione di utilizzare Transact-SQL o il codice gestito è la posizione in cui si desidera che risieda il codice, ovvero il computer server o il computer client. Sia Transact-SQL che il codice gestito possono essere eseguiti nel server. In questo modo il codice e i dati si troveranno vicini e sarà possibile usufruire delle capacità di elaborazione del server. D'altra parte, è possibile che si desideri evitare di collocare le attività che richiedono un utilizzo elevato del processore sul server di database. La maggior parte dei moderni computer client è piuttosto potente ed è possibile che si desideri usufruire di queste capacità di elaborazione posizionando la quantità maggiore possibile di codice sul client. Diversamente da Transact-SQL, il codice gestito può essere eseguito in un computer client.
Scelta tra stored procedure estese e codice gestito
Le stored procedure estese consentono di ottenere funzionalità altrimenti non disponibili con le stored procedure Transact-SQL. Diversamente dal codice gestito indipendente dai tipi, tuttavia, le stored procedure estese possono compromettere l'integrità del processo di SQL Server. La gestione della memoria, la pianificazione di thread e fiber e i servizi di sincronizzazione sono, inoltre, notevolmente più integrati tra il codice gestito di CLR e SQL Server. Grazie all'integrazione con CLR è possibile scrivere le stored procedure necessarie per eseguire attività non consentite in Transact-SQL in modo più sicuro rispetto alle stored procedure estese. Per ulteriori informazioni sull'integrazione con CLR e sulle stored procedure estese, vedere Prestazioni dell'integrazione con CLR.