Overzicht van CLR-integratie
van toepassing op:SQL ServerAzure SQL Managed Instance
De Common Language Runtime (CLR) is het hart van het .NET Framework en biedt de uitvoeringsomgeving voor alle .NET Framework-code. Code die binnen de CLR wordt uitgevoerd, wordt beheerde codegenoemd. De CLR biedt verschillende functies en services die nodig zijn voor het uitvoeren van programma's, waaronder JIT-compilatie (Just-In-Time), toewijzen en beheren van geheugen, afdwingen van typeveiligheid, uitzonderingsafhandeling, threadbeheer en beveiliging. Zie ontwikkelhandleiding voor .NET Frameworkvoor meer informatie.
Notitie
Zie .NET-runtime aanroepen in SQL Server Language Extensionsvoor meer informatie over het gebruik van de nieuwe .NET met SQL Server Language Extensions.
Met de CLR die wordt gehost in SQL Server (CLR-integratie), kunt u opgeslagen procedures, triggers, door de gebruiker gedefinieerde functies, door de gebruiker gedefinieerde typen en door de gebruiker gedefinieerde aggregaties in beheerde code ontwerpen. Omdat beheerde code wordt gecompileerd naar systeemeigen code voordat deze wordt uitgevoerd, kunt u in sommige scenario's aanzienlijke prestatieverbeteringen bereiken.
Beveiliging van codetoegang
In SQL Server 2016 (13.x) en eerdere versies voorkomt Code Access Security (CAS) dat assembly's bepaalde bewerkingen uitvoeren.
CLR maakt gebruik van CAS (Code Access Security) in .NET Framework, dat niet meer wordt ondersteund als een beveiligingsgrens. Een CLR-assembly die is gemaakt met PERMISSION_SET = SAFE
kan mogelijk toegang krijgen tot externe systeembronnen, onbeheerde code aanroepen en sysadmin-bevoegdheden verkrijgen. In SQL Server 2017 (14.x) en latere versies verbetert de sp_configure
optie, strikte beveiliging, de beveiliging van CLR-assembly's.
clr strict security
is standaard ingeschakeld en behandelt SAFE
en EXTERNAL_ACCESS
assembly's alsof ze zijn gemarkeerd als UNSAFE
. De optie clr strict security
kan worden uitgeschakeld voor achterwaartse compatibiliteit, maar wordt niet aanbevolen.
U wordt aangeraden alle assembly's te ondertekenen met een certificaat of asymmetrische sleutel, met een bijbehorende aanmelding die is verleend UNSAFE ASSEMBLY
machtiging in de master
-database. SQL Server-beheerders kunnen ook assembly's toevoegen aan een lijst met assembly's, die de Database Engine moet vertrouwen. Zie sys.sp_add_trusted_assemblyvoor meer informatie.
Voordelen van CLR-integratie
Transact-SQL is ontworpen voor directe gegevenstoegang en manipulatie in de database. Hoewel Transact-SQL excelleert in gegevenstoegang en -beheer, is het geen volwaardige programmeertaal. Transact-SQL biedt bijvoorbeeld geen ondersteuning voor matrices, verzamelingen, voor elke lus, bitverschuifing of klassen. Hoewel sommige van deze constructies kunnen worden gesimuleerd in Transact-SQL, heeft beheerde code geïntegreerde ondersteuning voor deze constructies. Afhankelijk van het scenario kunnen deze functies een overtuigende reden bieden om bepaalde databasefunctionaliteit in beheerde code te implementeren.
Visual Basic en C# bieden objectgeoriënteerde mogelijkheden, zoals inkapseling, overname en polymorfisme. Gerelateerde code kan nu eenvoudig worden ingedeeld in klassen en naamruimten. Wanneer u met grote hoeveelheden servercode werkt, kunt u met deze mogelijkheden uw code eenvoudiger ordenen en onderhouden.
Beheerde code is beter geschikt dan Transact-SQL voor berekeningen en ingewikkelde uitvoeringslogica, en biedt uitgebreide ondersteuning voor veel complexe taken, waaronder het verwerken van tekenreeksen en reguliere expressies. Met de functionaliteit in .NET Framework hebt u toegang tot duizenden vooraf gedefinieerde klassen en routines. Deze klassen kunnen eenvoudig worden geopend vanuit elke opgeslagen procedure, trigger of door de gebruiker gedefinieerde functie. De BCL (Base Class Library) bevat klassen die functionaliteit bieden voor het bewerken van tekenreeksen, geavanceerde wiskundige bewerkingen, bestandstoegang, cryptografie en meer.
Notitie
Hoewel veel van deze klassen beschikbaar zijn voor gebruik vanuit CLR-code in SQL Server, zijn deze niet geschikt voor gebruik aan de serverzijde (bijvoorbeeld vensterklassen), niet beschikbaar. Zie Ondersteunde .NET Framework-bibliothekenvoor meer informatie.
Een van de voordelen van beheerde code is typeveiligheid of de zekerheid dat code alleen op goed gedefinieerde, toegestane manieren toegang heeft tot typen. Voordat beheerde code wordt uitgevoerd, controleert de CLR of de code veilig is. De code wordt bijvoorbeeld gecontroleerd om ervoor te zorgen dat er geen geheugen wordt gelezen die nog niet eerder is geschreven. De CLR kan er ook voor zorgen dat code geen onbeheerd geheugen bewerkt.
CLR-integratie biedt het potentieel voor verbeterde prestaties. Zie Prestaties van clr-integratiearchitectuurvoor meer informatie.
Kiezen tussen Transact-SQL en beheerde code
Wanneer u opgeslagen procedures, triggers en door de gebruiker gedefinieerde functies schrijft, moet u beslissen of u traditionele Transact-SQL of een .NET Framework-taal zoals Visual Basic of C# wilt gebruiken. Gebruik Transact-SQL wanneer de code voornamelijk gegevenstoegang uitvoert met weinig of geen procedurele logica. Gebruik beheerde code voor CPU-intensieve functies en procedures die complexe logica bevatten of wanneer u de BCL van .NET Framework wilt gebruiken.
Kiezen tussen uitvoering op de server en uitvoering in de client
Een andere factor in uw beslissing over het gebruik van Transact-SQL of beheerde code is waar u uw code wilt opslaan, de servercomputer of de clientcomputer. Zowel Transact-SQL als beheerde code kan worden uitgevoerd op de server. Hiermee worden code en gegevens dicht bij elkaar geplaatst en kunt u profiteren van de verwerkingskracht van de server. Aan de andere kant wilt u misschien voorkomen dat processorintensieve taken op uw databaseserver worden geplaatst. De meeste clientcomputers zijn tegenwoordig krachtig en u wilt misschien profiteren van deze verwerkingskracht door zoveel mogelijk code op de client te plaatsen. Beheerde code kan worden uitgevoerd op een clientcomputer, terwijl Transact-SQL dat niet kan.
Kiezen tussen uitgebreide opgeslagen procedures en beheerde code
Uitgebreide opgeslagen procedures kunnen worden gebouwd om functionaliteit uit te voeren die niet mogelijk is met Transact-SQL opgeslagen procedures. Uitgebreide opgeslagen procedures kunnen echter de integriteit van het SQL Server-proces in gevaar brengen, terwijl beheerde code die is geverifieerd om typeveilig te zijn, niet mogelijk is. Verder zijn geheugenbeheer, planning van threads en vezels en synchronisatieservices dieper geïntegreerd tussen de beheerde code van de CLR en SQL Server. Met CLR-integratie hebt u een veiligere manier dan uitgebreide opgeslagen procedures om de opgeslagen procedures te schrijven die u nodig hebt om taken uit te voeren die niet mogelijk zijn in Transact-SQL. Zie Prestaties van clr-integratiearchitectuurvoor meer informatie over CLR-integratie en uitgebreide opgeslagen procedures.