Panoramica dell'integrazione con CLR
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 all'interno di CLR viene definito 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 altre informazioni, vedere Guida allo sviluppo di .NET Framework.
Nota
Per altre informazioni sull'uso della nuova estensione del linguaggio .NET con SQL Server, vedere Come chiamare il runtime .NET nelle estensioni del linguaggio di SQL Server.
Con CLR ospitato in SQL Server (denominato integrazione CLR), è 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 in codice nativo prima dell'esecuzione, è possibile ottenere miglioramenti significativi delle prestazioni in alcuni scenari.
Sicurezza dall'accesso di codice
In SQL Server 2016 (13.x) e versioni precedenti gli assembly non hanno impedito agli assembly di eseguire determinate operazioni.
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. In SQL Server 2017 (14.x) e versioni successive, l'opzione sp_configure clr strict security migliora 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. L'opzione clr strict security può essere disabilitata per la compatibilità con le versioni precedenti, ma non è consigliata.
È consigliabile firmare tutti gli assembly tramite un certificato o una chiave asimmetrica, con un account di accesso corrispondente a cui è stata concessa UNSAFE ASSEMBLY l'autorizzazione nel master database. Gli amministratori di SQL Server possono anche aggiungere assembly a un elenco di assembly, considerato attendibile dal motore di database. Per altre, vedere sys.sp_add_trusted_assembly.
Vantaggi dell'integrazione con CLR
Transact-SQL è progettato per l'accesso diretto ai dati e la manipolazione nel database. Mentre Transact-SQL eccelle nell'accesso e nella gestione dei dati, 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.
Visual Basic e C# offrono funzionalità orientate agli oggetti, ad esempio incapsulamento, ereditarietà e polimorfismo. Il codice correlato può ora essere organizzato facilmente in classi e spazi dei nomi. Quando si lavora con grandi quantità di codice server, queste funzionalità consentono di organizzare e gestire più facilmente il codice.
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. Con la funzionalità disponibile nella libreria .NET Framework, è possibile accedere a migliaia di classi e routine predefinite. È possibile accedere facilmente a queste classi da qualsiasi stored procedure, trigger o funzione definita dall'utente. La libreria di classi di base (BCL) include classi che forniscono funzionalità per la manipolazione delle stringhe, operazioni matematiche avanzate, accesso ai file, crittografia e altro ancora.
Nota
Anche se molte di queste classi sono disponibili per l'uso dal codice CLR in SQL Server, quelle non appropriate per l'uso lato server (ad esempio, le classi di windowing), non sono 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. Ad esempio, il codice viene controllato per assicurarsi che nessuna memoria venga letta che non è stata scritta in precedenza. CLR può anche garantire che il codice non manipola la memoria non gestita.
L'integrazione con CLR offre un potenziale miglioramento delle prestazioni. Per informazioni, vedere Prestazioni dell'architettura di integrazione CLR.
Scegliere 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 o C#. Usare Transact-SQL quando il codice esegue principalmente l'accesso ai dati con logica procedurale o poco. 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.
Scegliere tra l'esecuzione nel server e l'esecuzione 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 evitare di inserire attività a elevato utilizzo di processore nel server di database. La maggior parte dei computer client oggi è potente e può essere utile sfruttare questa potenza di elaborazione inserendo il maggior numero di codice possibile sul client. Il codice gestito può essere eseguito in un computer client, mentre Transact-SQL non può.
Scegliere 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'architettura di integrazione CLR.