VB.NET oder T-SQL ?

Mit VB.NET und T-SQL werden von Microsoft zwei völlig unterschiedliche Programmiermöglichkeiten zur Verfügung gestellt. Beide haben ihre Berechtigung und ihre bevorzugte Anwendung. Es stellt sich natürlich die Frage, wann VB.NET und wann T-SQL verwendet werden sollte.
Die grobe Regel lautet: Verwenden Sie T-SQL für die datenbanknahe und VB.NET für die hauptspeicherintensive Programmierung.
Die Nähe zur Datenbank bezieht sich in diesem Zusammenhang auf den Ort der Programmausführung.
T-SQL-Programme werden direkt auf dem Datenbankserver ausgeführt. Im Gegensatz dazu erfolgt die Ausführung von VB.NET-Programmen im Hauptspeicher des aufrufenden Computers.
Der T-SQL-Programmcode wird als Text an den SQL Server übergeben. Der Text wird vom Server interpretiert und ausgeführt. T-SQL ist ein Feature des SQL Servers, welches in den Integration Services genutzt wird. Sie können T-SQL auf dem SQL Server auch völlig unabhängig von den Integration Services nutzen.
Als Beispiel sei das SQL Server Management Studio genannt, welches sich sehr gut für das Absetzen von T-SQL-Programmcode eignet. Die notwendigen Rechte vorausgesetzt, kann der T-SQL-Code auch über jede andere SQL Server-Datenbankverbindung ausgeführt werden. In den Integration Services können Sie darüber hinaus T-SQL in den Paketablauf integrieren und mit anderen Integration Services-Komponenten kombinieren.
Mit der Übergabe des T-SQL-Textes wird dem SQL Server eine Arbeitsanweisung gegeben. Die Ausführung dieser Anweisung erfolgt ausschließlich auf dem Server selbst. Der Client wartet nach dem Absetzen des T-SQL-Textes auf einen Response des Servers. Das kann die Meldung über die erfolgreiche Ausführung sein, eine Fehlermeldung oder die mit einem Select-Statement angeforderte Ergebnismenge.
Da die gesamte Verarbeitung auf dem Server stattfindet, eignet sich T-SQL besonders für Anwendungen, die überwiegend auf dem Server selbst ablaufen. Der Netzwerktraffic kann dadurch erheblich reduziert werden und insbesondere beim Kopieren von Massendaten ist die Ausführung auf dem Server schneller.
T-SQL eignet sich weniger für die Ausführung von komplexem Programmcode. So ist es zwar möglich mit Programmschleifen und Cursors zu arbeiten, aber die Performance ist bei großen Datenmengen erschreckend schlecht. Aus diesem Grund wurde in DTS-Paketen vielfach die Komplexität der Statements durch die Einführung einer Staging-Area reduziert. Eine Staging-Area ist ein Bereich auf dem SQL Server, in dem temporäre Tabellen gehalten werden. Die Daten werden als Zwischenergebnis in den Tabellen der Staging-Area gespeichert. Dadurch sind die Aufgaben für den Server und T-SQL weniger komplex und können schneller ausgeführt werden. Durch die zusätzliche Verwendung von Staging-Tabellen erhöhen sich die Schreib- und Lesezugriffe auf dem Datenbankserver erheblich. Dies reduziert natürlich die Serverperformance.
Das bedeutet aber nicht, dass Sie nun alle T-SQL-Programme umschreiben sollen, nur weil Sie eine Staging-Area verwenden. Es gibt sehr viele, gut funktionierende DTS-Pakete, bei denen es keine Notwendigkeit gibt, deren Programmlogik umzuschreiben. Es sei auch angemerkt, dass es in manchen Anwendungen einfacher ist, Daten auf dem SQL Server in einer Staging-Area zwischenzuspeichern, als sie im Hauptspeicher mit VB.NET hin und her zu jonglieren.
VB.NET-Programme hingegen laufen auf dem Computer, welcher das Integration Services-Paket ausführt. Es wird ein so genannter verwalteter Code in der CLR (Common Language Runtime) des .NET-Frameworks ausgeführt.
Die VB.NET-Programme werden genauso ausgeführt wie alle anderen Integration Services-Komponenten auch: Jedes Skript wird nach dem Verlassen des Microsoft Visual Studio für Applikationen automatisch kompiliert (Voraussetzung: Eigenschaft PrecompileSkriptIntoBinaryCode = True) und als (Paket-)Assembly gespeichert. Bei der Ausführung wird kein Unterschied zwischen den Standardkomponenten und den VB.NET-Programmen gemacht. Alles läuft im Hauptspeicher des Computers ab, der das Integration Services-Paket ausführt. Der Vorteil dieser Art der Programmausführung ist die enorme Schnelligkeit.
Damit Daten mit einer Skriptkomponente bearbeitet werden können, müssen Sie in den Datenfluss eingelesen werden. Die nachfolgenden Überlegungen zum Trafficaufkommen im Netzwerk betreffen also nicht nur die Skriptkomponente, sondern alle Anwendungen, die Daten in den Datenfluss laden.
Ist der ausführende Computer nicht der Datenbankserver, müssen die angeforderten Daten über das Netzwerk transportiert werden. Dies kann bei größeren Datenmengen zu einer erheblichen Belastung des Netzwerks führen.
Wird der SQL Server Agent auf dem Datenbankserver selbst ausgeführt und wird die Paketausführung durch den SQL Server Agent angestoßen, entfällt der zusätzliche Traffic im Netzwerk. Denn in dieser Konstellation werden nur Daten zwischen zwei Prozessen auf dem Datenbankserver ausgetauscht. Dieser Austausch geht sehr schnell.
Ist die Bereitstellung der Daten für den Datenfluss ein Problem, sollte alternativ die Verwendung von T-SQL geprüft werden.
Sind die Daten aber erst einmal im Datenfluss eingelesen, sind die Standardkomponenten und das Skripting so mächtig, dass in der Mehrzahl der Fälle eine Staging-Area vollkommen vermieden werden kann. Die Performance bei der Datenmanipulation im Datenfluss ist um ein vielfaches größer als auf dem Server unter Verwendung von T-SQL. Standardkomponenten und die Skriptkomponente sollte dabei geschickt gemeinsam genutzt werden.
Sie müssen sich jedoch nicht auf eine Art der Programmierung festlegen. T-SQL und VB.NET lassen sich sehr gut gemeinsam nutzen. In einer OLE DB-Quelle können Sie ein vollständiges T-SQL-Programm an den Server übergeben. Der Server führt das T-SQL-Programm aus, eventuell auch unter Nutzung einer Staging-Area auf dem Server, und gibt die Ergebnismenge zurück. Diese Ergebnismenge ist die Quelle des Datenflusses. Im Datenfluss selbst verwenden Sie das Skripting um die Daten weiter zu bearbeiten. T-SQL und VB.NET arbeiten Hand in Hand.
Fazit: T-SQL hat weiterhin seine Berechtigung. Für die Verarbeitung von großen Datenmengen auf einem Server ist T-SQL die beste Lösung. Bei der Entwicklung von DTS-Paketen war T-SQL bislang die wichtigste Programmiersprache. Diese hervorgehobene Rolle hat T-SQL nun durch die Einführung der Integration Services verloren. VB.NET ist nun für viele Anwendungen die bessere Alternative. Durch die Funktionsvielfalt des .NET-Frameworks eröffnen sich zahlreiche neue Lösungsmöglichkeiten, welche unter anderem die permanente Verwendung einer Staging-Area überflüssig machen.