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 è progettato specificamente per l'accesso diretto ai dati e la manipolazione nel database. Mentre Transact-SQL eccelle nell'accesso ai dati e nella gestione, non è un linguaggio di programmazione completo. Ad esempio, Transact-SQL non supporta matrici, raccolte, cicli for-each, spostamento dei bit o classi. Anche se alcuni di questi costrutti possono essere simulati in Transact-SQL, il codice gestito ha integrato il supporto per questi 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 è più adatto a Transact-SQL per calcoli e logica di esecuzione complicata e offre un ampio supporto per molte 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

Quando si scrivono stored procedure, trigger e funzioni definite dall'utente, è necessario decidere se usare Transact-SQL tradizionale o un linguaggio .NET Framework, ad esempio Visual Basic .NET o Visual C#. Usare Transact-SQL quando il codice eseguirà principalmente l'accesso ai dati con logica procedurale o scarsa. 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 nella decisione relativa all'uso di Transact-SQL o del codice gestito è la posizione in cui risiedere il codice, il computer server o il computer client. Sia Transact-SQL che 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. Il codice gestito può essere eseguito in un computer client, mentre Transact-SQL non può.

Scelta tra stored procedure estese e codice gestito

Le stored procedure estese possono essere compilate per eseguire funzionalità non possibili con le stored procedure Transact-SQL. Le stored procedure estese possono tuttavia compromettere l'integrità del processo di SQL Server, mentre il codice gestito verificato non può essere indipendente dai tipi. Inoltre, la gestione della memoria, la pianificazione di thread e fibre e i servizi di sincronizzazione sono più profondamente integrati tra il codice gestito di CLR e SQL Server. Con l'integrazione con CLR, è disponibile un modo più sicuro rispetto alle stored procedure estese per scrivere le stored procedure necessarie per eseguire attività non possibili in Transact-SQL. Per altre informazioni sull'integrazione con CLR e sulle stored procedure estese, vedere Prestazioni dell'integrazione con CLR.

Vedi anche

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