Artikel als PDF anzeigen

ITMAGAZINE
SQL Server 2005: .Net im Tank
von Urs Bertschy
6. Oktober 2005 - Dank der Integration von .Net lässt sich Microsofts Datenbankserver auch mit VB.Net oder C#
programmieren. 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
• 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.
Copyright by Swiss IT Media 2017