Integrazione CLR - Panoramica

Si applica a: SQL Server Istanza gestita di SQL di Azure

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 sicurezza. 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 sicurezza dall'accesso di codice (CAS) per gli assembly eseguano determinate operazioni. In SQL Server viene usato CAS per proteggere il codice gestito e per impedire il danneggiamento del sistema operativo o del server di database.

Vantaggi dell'integrazione con CLR

Transact-SQL è stato progettato specificamente 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. Ad esempio, Transact-SQL non supporta array, raccolte, cicli For Each, spostamenti di bit o classi. Mentre in Transact-SQL è possibile simulare alcuni di questi costrutti, il codice gestito dispone del supporto integrato per tali costrutti. A seconda dello scenario, l'implementazione di determinate caratteristiche 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ù adatto di Transact-SQL per i calcoli e per una logica di esecuzione complessa. Inoltre dispone di un supporto esteso per numerose attività complesse, tra cui 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 altre 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 informazioni, vedere Prestazioni dell'integrazione CON CLR.

Avviso

CLR usa la Sicurezza dall'accesso di codice (CAS, Code Access Security) in .NET Framework, non più supportata come limite di sicurezza. Un assembly CLR creato con PERMISSION_SET = SAFE potrebbe essere in grado di accedere alle risorse di sistema esterne, chiamare codice non gestito e acquisire privilegi sysadmin. A partire da SQL Server 2017 (14.x), è disponibile un'opzione sp_configure denominata clr strict security che consente di incrementare la sicurezza degli assembly CLR. clr strict security è abilitata per impostazione predefinita e considera gli assembly CLR SAFE e UNSAFE come se fossero contrassegnati EXTERNAL_ACCESS. È possibile disabilitare l'opzione clr strict security per la compatibilità con le versioni precedenti, ma questa operazione è sconsigliata. Microsoft consiglia che tutti gli assembly siano firmati con un certificato o una chiave asimmetrica con un account di accesso corrispondente che disponga dell'autorizzazione UNSAFE ASSEMBLY nel database master. Per altre informazioni, vedere CLR strict security.

Scelta tra Transact-SQL e codice gestito

Durante la scrittura di stored procedure, trigger e funzioni definite dall'utente, è necessario decidere se utilizzare il tradizionale Transact-SQL o un linguaggio .NET Framework come 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 fattore da tenere presente quando si decide se utilizzare Transact-SQL o codice gestito è la posizione in cui si desidera che risieda il codice, ovvero nel server o nel client. È possibile eseguire sul server sia Transact-SQL che il codice gestito. 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. Su un client è possibile eseguire il codice gestito, ma non Transact-SQL.

Scelta tra stored procedure estese e codice gestito

Le stored procedure estese possono essere create per eseguire funzionalità che non sono disponibili con le stored procedure di Transact-SQL. Tuttavia, mentre le stored procedure estese possono compromettere l'integrità del processo SQL Server, il codice gestito type-safe è sicuro. Inoltre, la gestione della memoria, la pianificazione di thread e fiber e i servizi di sincronizzazione sono più profondamente integrati tra il codice gestito 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 altre informazioni sull'integrazione clr e sulle stored procedure estese, vedere Prestazioni dell'integrazione CLR.

Vedere anche

Installazione di .NET Framework
Architettura dell'integrazione con CLR
Accesso ai dati da oggetti di database CLR
Introduzione all'integrazione con CLR