SQL Server 2005: .Net im Tank

Die vielleicht spektakulärste Neuerung des für November angekündigten SQL Server 2005 ist die Integration der Common Language Runtime des .Net Framework in die Datenbank-Engine. Dadurch wird man künftig Datenbank-Code nicht nur mit T-SQL, sondern auch mit den .Net-Sprachen Visual Basic oder C# schreiben können. Die Ausführung des Codes wird dabei direkt in die Datenbank verlagert.

Die Vorteile der CLR-Integration

Entwickler erhalten somit nicht nur die Möglichkeit, auf die Vorzüge einer objektorientierten Hochsprache zurückgreifen zu können, sondern werden künftig in der Lage sein, einen Teil der Datenbankkomponenten mit derselben Sprache zu programmieren wie den Code in den übrigen Applikationsschichten. Zudem eröffnet die .Net-Integration bereits auf Datenbankebene den Zugang zu einem Grossteil der Klassen des .Net Framework und auch auf Bibliotheken von Drittanbietern.
Ein weiteres Plus: Für .Net geschriebene SQL-Server-2005-Komponenten liegen als kompilierte Assemblies vor und können dadurch nicht nur von einer höheren Performance, sondern auch von den wesentlich besseren Security-Mechanismen der.Net-Umgebung profitieren. So wird der Code beispielsweise auf Typensicherheit und notwendige Berechtigungen geprüft, bevor er ausgeführt wird.

Eigene Aggregates und Datentypen

Konkret lassen sich Stored Procedures, Triggers, UDFs (User Defined Functions), Aggregates und UDTs (User Defined Data Types) mit .Net Code schreiben. Die beiden letztgenannten sind komplett neue Features in SQL Server 2005. Mit den Aggregates kann SQL Server um eigene Aggregierungsfunktionen erweitert werden. Via User Defined Data Types dagegen lassen sich die Standard-Datentypen des SQL Server um eigene Typen ergänzen. Diese werden ebenfalls mit .Net Managed Code erstellt und lassen sich ganz normal als Feldtypen in Tabellenspalten verwenden. UDTs sind vor allem für eine präzisere Formulierung von Datentypen gedacht. Entwickler erhalten damit eine feinkörnigere Kontrolle über das Datenmaterial und können dadurch eine konsistente Datenhaltung sicherstellen. Typische Anwendungsbeispiele für UDTs wären etwa Typen für geografische Koordinaten oder spezifische Datum/Zeit-Typen.

T-SQL versus Managed Code

Auch wenn T-SQL als Database Manipulation Language (DML) sehr mächtig ist, so sind viele Aufgaben mit Microsofts SQL-Sprache nur sehr schwer oder gar nicht realisierbar. Typische Beispiele dafür sind etwa Verschlüsselung, rekursive Operationen, komplexe Validierungen, String-Manipulationen oder mathematische Berechnungen. Ein wichtiger Trumpf, welcher die .Net Plattform hier ausspielen kann, ist – wie eingangs bereits erwähnt – das riesige Klassenangebot des .Net Framework. Entwickler erhalten damit Zugriff auf Funktionen wie etwa Kryptographie-Algorithmen, XML-Manipulation, Regex-Validierung, Berechnungsfunktionen, Datumsoperationen oder Bildverarbeitung. Des weiteren erhalten sie auch Zugriff auf externe Ressourcen wie Dateisystem, Event-Log oder Web Services.
Wer beispielsweise eine Regex-Prüfung zum Validieren einer Telefonnummer schreiben wollte, wurde von T-SQL im Regen stehengelassen. Mit einer Sprache wie C# oder Visual Basic ist die Implementation einer solchen Funktion eine Sache von wenigen Codezeilen. Ebenfalls mit geringem Aufwand lässt sich ein Trigger realisieren, der bei Datenupdates eine Benachrichtigung via E-Mail absetzt oder einen Eintrag im Eventlog vornimmt.
Ein weiterer Vorteil: .Net ist bei den oben genannten Aufgaben T-SQL auch in Sachen Performance überlegen. Eine in Form eines kompilierten Assembly vorliegende Berechnungsfunktion wird um ein Vielfaches schneller ausgeführt als eine entsprechende Routine, die in T-SQL geschrieben wurde.

Keine Allzweckwaffe

Wer nun den Eindruck gewonnen hat, T-SQL ist mit der .Net-Fähigkeit des SQL Server obsolet geworden, liegt falsch. Vor allem dann, wenn es um Datenzugriffe und datenintensive Operationen geht, ist T-SQL nach wie vor die bessere Wahl. Hinzu kommt, dass es in C# oder Visual Basic kein Equivalent zu Datenmanipulations-Statements wie SELECT oder INSERT gibt. Wer Daten aus einer .Net-Sprache manipulieren will, muss nach wie vor T-SQL-Strings verwenden. Selbst eine Stored Procedure, die in C# geschrieben wurde, muss auf T-SQL zurückgreifen, wenn beispielsweise Daten aus der Datenbank selektiert werden sollen. .Net ist vielmehr als Ergänzung zu T-SQL zu sehen, mit der das Spektrum an Möglichkeiten, Datenbankcode zu schreiben, erheblich erweitert wird. Damit haben Entwickler künftig aber auch die Qual der Wahl. Wann soll Code in .Net und wann in SQL geschrieben werden? Dazu gibt es einige Faustregeln:

• Falls der Code in erster Linie auf Daten zugreift und diese manipuliert, sollte auf T-SQL zurückgegriffen werden. Punkto Datenzugriffsgeschwindigkeit kann CLR-Code niemals mit der Performance von T-SQL mithalten.

• Falls der Code primär rechenintensive Operationen (String-Manipulationen, mathematische Berechnungen etc.) durchführt, ist CLR erste Wahl.

• Falls Funktionen aus dem .Net Framework genutzt werden sollen, kommt nur .Net in Frage.



Schwieriger wird es dann, wenn mehrere der obgenannten Bedingungen zutreffen. Zum Beispiel dann, wenn aus dem Code heraus sowohl auf Daten als auch auf Features des .Net Framework zugegriffen werden soll. Mögliche Optionen wären in diesem Fall, das ganze Programmteil in .Net-Code zu schreiben oder aber den .Net-relevanten Code in eine Funktion auszulagern und diesen aus einer T-SQL-Prozedur aufzurufen. Die erste Möglichkeit ist dann von Vorteil, wenn die Datenzugriffe nur minimal ausfallen. Sind die Zugriffe aber intensiv, wird wohl eher die zweite Option in Frage kommen. So wird man sich in vielen Fällen in einer Grauzone bewegen, in der man Vor- und Nachteile der zur Verfügung stehenden Lösungsansätze gegeneinander abwägen und das Vorgehen genau planen muss.
Grundsätzlich sollte man sich auch immer vor Augen halten, dass CLR-Code auf dem Datenbankserver ausgeführt wird. Vor allem bei einer grossen Zahl an Client-Zugriffen können sich rechenintensive Operationen negativ auf die Serverperformance auswirken.

Neues aus dem T-SQL-Land

C# und Visual Basic hin oder her; alleine die grosse Palette an Neuerungen zeigt, dass T-SQL auch künftig eine wichtige Rolle spielen wird. Nachfolgend die wichtigsten im Überblick:

• Common Table Expressions (CTE): CTEs erlauben das Definieren von virtuellen Tabellen, auf die aus einer SQL-Abfrage Bezug genommen werden kann.

• Rekursive Queries: Neu lassen sich rekursive Abfragen formulieren. Sie werden auf Basis der oben genannten CTEs formuliert.

• Exception Handling: Neu wird auch strukturiertes Exception Handling mit einem TRY/CATCH-Block geboten, der innerhalb von Transaktionen genutzt werden kann.

• Pivot-Operator: Mit dem Pivot-Operator lassen sich Zeilen und Spalten zwecks Datenanalyse flexibel vertauschen und rotieren.

• Neue Datentypen: Die Datenbank-Engine unterstützt neue Datentypen, wie etwa einen von der Lokalität abhängigen Datum/Zeit-Typ (utcdatetime) oder separate Typen für Datum (date) und Zeit (time). Ausserdem kann jetzt die Grösse von variablen Datentypen (varchar, varbinary etc.) mit dem Schlüsselwort MAX gesteuert werden.

• Ranking: Eine Gruppe von neuen Funktionen vereinfacht es, Daten mit Rängen zu bewerten.