Vergleichen der SQL Server-Spracherweiterungen mit der SQL CLR
Gilt für: 
SQL Server 2019 (15.x) und höhere Versionen
In diesem Artikel werden SQL Server-Spracherweiterungen und die native Common Language Runtime (CLR) miteinander verglichen. Die wichtigsten Unterschiede zwischen ihnen werden vorgestellt, sodass Sie besser entscheiden können, was Sie verwenden möchten.
SQL Server-Spracherweiterungen sind ein Feature von SQL Server zum Ausführen von externem Code. Die relationalen Daten können über das Erweiterbarkeitsframework im externen Code verwendet werden.
Mit der nativen Common Language Runtime (CLR) können Sie einige der Funktionen von SQL Server mit .NET-Sprachen implementieren. Die CLR-Komponente stellt verwalteten Code mit Diensten bereit, wie z. B. sprachübergreifende Integration, Codezugriffssicherheit, Verwaltung der Objektlebensdauer und Debug- und Profilerstellungsunterstützung.
Die in SQL Server-Spracherweiterungen verfügbaren Sprachen sind kein direkter Ersatz für die SQL CLR. Das Erweiterbarkeitsframework und die Spracherweiterungen erweitern die Oberfläche von SQL Server und stellen eine Ausführungsumgebung für Runtimes bereit, die sich näher an der Datenbank-Engine befinden. Außerdem stellen sie ein Open-Source-Framework bereit, mit dem neue Runtimes ohne Änderungen an der Engine integriert werden können. Derzeit ist die Oberfläche auf die gespeicherte Systemprozedur sp_execute_external_script beschränkt.
Im Folgenden werden einige der wichtigsten Unterschiede zwischen SQL-Spracherweiterungen und der SQL CLR erläutert:
| Feature | SQL CLR | SQL-Spracherweiterungen |
|---|---|---|
| Plattformunterstützung | Windows und Linux - Linux unterstützt nur SAFE-Assemblys. |
Windows und Linux: vollständige Parität in Bezug auf die Funktionalität. |
| Ausführungsmodus | Prozessintern | Prozessextern |
| Isolation | CLR-Code wird innerhalb des Engine-Prozesses ausgeführt; der Instanzadministrator muss allen Assemblys bzw. dem gesamten Code vertrauen. | Die Laufzeitausführung erfolgt außerhalb des Engine-Prozesses. Eine weitere Ebene der Isolation wird mithilfe von App-Containern unter Windows oder Namespaces unter Linux bereitgestellt. Die externe Netzwerkkommunikation ist ebenfalls standardmäßig deaktiviert. |
| Deklarative Syntax (T-SQL) | Benutzerdefinierte Typen, benutzerdefinierte Aggregate, Funktionen, Prozeduren, Trigger. | Nur Ad-hoc-Ausführung mit sp_execute_external_script. |
| DDL-Unterstützung | CREATE ASSEMBLY zum Hochladen von Benutzercode und Definieren anderer Objekte (Funktionen, Prozeduren, Trigger-UDTs, UDAggs). |
CREATE EXTERNAL LANGUAGE, EXTERNAL LIBRARY, um Erweiterungen und Bibliotheken zu verwalten. |
| Bibliotheksunterstützung | Wird über Assemblys erreicht. | Es können Bibliotheken für eine bestimmte Runtime verwendet werden (z. B. R- oder Python-Pakete, Java-Bibliotheken). |
| Unterstützte Runtimes | .NET Framework | R, Python, Java, C# oder Bring Your Own Runtime (BYOR). |
| OSS-Framework | Nicht zutreffend – kann über benutzerdefinierte .NET-Assemblys erweitert werden. | Ja – das Erweiterungs-SDK ermöglicht die Erstellung neuer Erweiterungen oder die Integration in Runtimes ohne Engine-Änderungen. |
| QO-Integration | Integration auf Operatorebene für verschiedene Syntaxen, einschließlich Parallelität. | Einzelner externer Skriptoperator zum Senden/Empfangen von Ergebnissen und Daten von Runtimes. Dieser Operator unterstützt Batchmodusausführung und Parallelität. |
| Ressourcengovernance | Keine – wenige Optionen außerhalb des Resource Governors. | Stellt das EXTERNAL RESOURCE POOL-Objekt als separaten Mechanismus zum Steuern von Ressourcen bereit, die von den Laufzeitskripts/externen Skripts genutzt werden. Richtlinien können für externe Runtimes zusätzlich zur SQL-Arbeitsauslastung definiert werden. |
| Berechtigungsmodell | Steuerung auf Instanzebene mit Objekten im Gültigkeitsbereich der Datenbank. | Steuerung auf Instanzebene mit Objekten im Gültigkeitsbereich der Datenbank. |
| Leistung | SQL CLR-Code ist in der Regel aufgrund der Art der Ausführung leistungsfähiger als die Erweiterbarkeit. | Ideal für eine batchorientierte Ausführung. |
| Überwachungsfunktionen | sys.dm_clr*-DMVs und eingeschränkter SQL CLR-spezifischer Leistungsüberwachungs-Zähler. |
sys.dm_external*-DMVs, externe Ressourcenpool-DMVs, Windows Jobobject-Leistungsüberwachungs-Zähler. |
Einsatzgebiete der jeweiligen Varianten
Ob Sie Spracherweiterungen oder die CLR verwenden, hängt von Ihren Szenarien und Zielen ab. Wenn Sie z. B. die T-SQL-Oberfläche um Ihre eigenen Aggregate oder Typen erweitern müssen, ist die CLR die beste Wahl, da Typ oder Aggregat mit dem Erweiterbarkeitsmechanismus nicht definiert werden können. Wenn Sie andererseits vorhandene Data-Science-Kenntnisse in Ihrer Organisation oder Ihrem Team nutzen möchten, ist die Verwendung der R/Python-Integration mit Erweiterbarkeit die beste Wahl.
Ebenso können Ihre Leistungsziele Ihre Entscheidung bestimmen. Das Implementieren einer RegEx-Funktion in C# und die Verwendung der CLR ist viel schneller als die Verwendung der Erweiterbarkeit zum Aufrufen eines Python-Skripts, das die gleiche RegEx-Funktionalität ausführt.