Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL Server 2019 (15.x) och senare versioner
I den här artikeln jämförs SQL Server Language Extensions och CLR (Native Common Language Runtime). Den identifierar de viktigaste skillnaderna mellan dem och hjälper dig att bestämma vilken som ska användas.
SQL Server Language Extensions är en funktion i SQL Server som används för att köra extern kod. Relationsdata kan användas i den externa koden med hjälp av utökningsramverket.
Med CLR (Native Common Language Runtime) kan du implementera några av funktionerna i SQL Server med .NET-språk. CLR tillhandahåller hanterad kod med tjänster som integrering mellan språk, säkerhet för kodåtkomst, hantering av objektlivslängd samt stöd för felsökning och profilering.
De språk som är tillgängliga i SQL Server Language Extensions är inte en direkt ersättning för SQL CLR. Utökningsramverket och språktilläggen utökar ytan på SQL Server och tillhandahåller en körningsmiljö för körning närmare databasmotorn. De tillhandahåller också ett ramverk med öppen källkod som kan användas för att registrera nya körningar utan motorändringar. För närvarande är ytan begränsad till systemets lagrade procedur, sp_execute_external_script.
Följande är några av de viktigaste skillnaderna mellan SQL Language Extensions och SQL CLR:
| Egenskap | SQL CLR | SQL Language-tillägg |
|---|---|---|
| Plattformsstöd | Windows & Linux – Linux stöder endast SAFE sammansättningar. |
Windows & Linux – fullständig paritet när det gäller funktioner. |
| Körningsläge | In-proc | Out-of-proc |
| Isolering | CLR-kod körs inom motorprocessen; instansadministratören måste lita på alla sammansättningar/kod. | Körningen sker utanför motorprocessen. Ytterligare isolering tillhandahålls med appcontainrar i Windows eller namnområden i Linux. Extern nätverkskommunikation är också inaktiverad som standard. |
| Deklarativ syntax (T-SQL) | Användardefinierade typer, användardefinierade aggregeringar, funktioner, procedurer, utlösare. | Endast ad hoc-körning med .sp_execute_external_script |
| DDL-stöd |
CREATE ASSEMBLY för att ladda upp användarkod och definiera andra objekt (funktioner, procs, triggers UDTs, UDAggs). |
CREATE EXTERNAL LANGUAGE, EXTERNAL LIBRARY för att hantera tillägg och bibliotek. |
| Biblioteksstöd | Uppnås via sammansättningar. | Bibliotek för specifik körning kan användas (till exempel R- eller Python-paket, Java-bibliotek). |
| Körningar som stöds | .NET Framework | R, Python, Java, C# eller Bring your own runtime (BYOR). |
| OSS-ramverk | N/A – kan utökas via användardefinierade .NET-sammansättningar. | Ja – tilläggs-SDK ger redigering av nya tillägg eller integrering med runtimes utan motorändringar. |
| QO-integrering | Integrering på operatornivå för olika syntaxer, inklusive parallellitet. | Den här operatorn har stöd för körning och parallellitet i batchläge för att skicka/ta emot resultat och data från körningsmiljöer. |
| Resursstyrning | Ingen - få knoppar utanför resursguvernören. | Tillhandahåller EXTERNAL RESOURCE POOL objekt som en separat mekanism för att styra resurser som förbrukas av körnings-/externa skript. Principer kan definieras för externa körningar utöver SQL-arbetsbelastningen. |
| Behörighetsmodell | Instansnivåkontroll med db-begränsade objekt. | Instansnivåkontroll med db-begränsade objekt. |
| Performance | SQL CLR-kod överträffar vanligtvis utökningsbarheten på grund av körningens natur. | Perfekt för batchorienterad körning. |
| Övervakningsfunktioner |
sys.dm_clr* DMV:er och begränsad SQL CLR-specifik prestandaövervakareräknare. |
sys.dm_external* DMV:er, externa resurspool-DMV:er, Prestandaövervakare för Windows JobObject. |
När du ska använda varje
Om du använder språktillägg eller CLR beror på dina scenarier och mål. Om du till exempel behöver utöka T-SQL-ytan med dina egna aggregat eller typer är CLR det bästa valet eftersom typ eller aggregering inte kan definieras med hjälp av utökningsmekanismen. Om du däremot vill använda befintlig expertis inom datavetenskap i din organisation eller ditt team är det bästa valet att använda R/Python-integrering med utökningsbarhet.
På samma sätt kan dina prestandamål avgöra ditt beslut. Det går mycket snabbare att implementera en regex-funktion i C# och använda CLR än att använda utökningsbarhet för att anropa ett Python-skript som utför samma regex-funktioner.