SQL Server 2008 - Der schnelle Einstieg - Abfragen, Transact-SQL, Entwicklung und Verwaltung

Dieses Buch bietet Ihnen einen leichten und schnellen Einstieg in Einsatz, Verwaltung und Entwicklung einer Datenbank mit dem SQL Server 2008 - von der Express bis zur Enterprise Edition. Klemens Konopasek berücksichtigt alle wichtigen Neuerungen wie z.B. Geodaten, Filestream oder Change Data Capture. Sein Schwerpunkt liegt auf der Lösungsentwicklung mit TransactSQL, aber auch die CLR-Integration mit dem NET Framework 3.5 kommt nicht zu kurz. An DBAs richten sich die Kapitel zur Benutzerverwaltung und Berechtigungsvergabe.

6 Gespeicherte Prozeduren, Funktionen und Trigger (S. 267-268)

Im vorangegangenen Kapitel haben Sie gelernt, wie die Sprache Transact-SQL aufgebaut ist, woraus sie besteht und welcher Syntax sie folgt. In diesem Kapitel werden wir diese Sprache zum Erstellen von Datenbankobjekten benutzen. Da im vorigen Kapitel die Techniken erläutert wurden, die in diesem Kapitel zum Einsatz kommen, sollten Sie das vorige Kapitel nicht übersprungen haben, wenn Sie sich diesem Kapitel widmen.

Die klassischen mit Transact-SQL programmierbaren Datenbankobjekte sind: Gespeicherte Prozeduren (Stored Procedures) Benutzerdefinierte Funktionen (Userdefined Functions/UDFs) Trigger Durch die Integration der Common Language Runtime (CLR) können Prozeduren, Funktionen und Trigger seit der Version 2005 auch mit einer .NET-Programmiersprache anstelle von Transact-SQL programmiert werden. Dies ist dann sinnvoll, falls nicht Datenzugriffe, sondern komplexe Algorithmen im Vordergrund der Lösung stehen. Für klassische Datenbankaufgaben ist der Einsatz von Transact-SQL die wesentlich bessere und bewährtere Variante.

Bei und vor der Einführung von SQL Server 2005 hat es viele Diskussionen zur Frage gegeben, ob Transact-SQL damit nun »tot« sei. Dies ist schon damals mit dem Argument verneint worden, dass es für beide Varianten klare Einsatzbereiche gibt, in denen die eine Variante der anderen überlegen ist. .NET-Prozeduren waren schon immer als Ergänzung zu T-SQL gedacht, um jene Bereiche abzudecken, für die T-SQL nicht so gut oder gar nicht geeignet ist. Außerdem kommt man beim Einsatz von .NET-Prozeduren nicht ohne T-SQL aus. In der Praxis hat T-SQL seine Bedeutung nicht eingebüßt – es ist nach wie vor sehr bedeutend.

Durch neue Features hat seine Bedeutung eher noch zugenommen. Andererseits habe ich in den letzten Jahren die Möglichkeiten der .NET-Integration für Spezialaufgaben sehr zu schätzen gelernt. Eine weitere immer wieder auftauchende Diskussion ist, ob der Einsatz von serverseitiger Datenbankprogrammierung generell sinnvoll ist. Dazu möchte ich Folgendes bemerken: Es gibt Fälle, in denen tatsächlich Argumente gegen den Einsatz solcher Technologien sprechen. Das ist immer der Fall, wenn das Datenbanksystem hinter einer Anwendung austauschbar sein soll. Zum Beispiel bei der Entwicklung einer Standardsoftware, bei der der Kunde das verwendete Datenbanksystem aus verschiedenen Systemen auswählen können soll.

In diesen Szenarien wird man Geschäftslogiken in eigenen Klassen abbilden, welche mit Standardschnittstellen wie zum Beispiel ADO.NET unter der Verwendung von ANSI-SQL-Anweisungen ohne die Nutzung produktspezifischer Möglichkeiten auf die Datenbank zugreifen. Nur so kann das Datenbanksystem hinter der Anwendung ohne großen Aufwand ausgetauscht werden. Leider werden hier aber in der Regel spezielle Fähigkeiten bestimmter Datenbanksysteme nicht ausgenutzt. Sinnvoll hingegen ist der Einsatz der beschriebenen Technologien, wenn der SQL Server das von Ihnen verwendete Datenbanksystem ist und ein Wechsel auf ein anderes System nicht angedacht ist. Denn durch den Einsatz serverseitiger Programmierung nutzen Sie das Potential des Systems voll aus. Da die Syntax allerdings produktspezifisch ist, wäre der Wechsel des Systems mit einem erhöhten Aufwand verbunden. Die Programmierung mit T-SQL ist sehr einfach und schnell zu realisieren. Dieselben Aufgaben mit einer anderen Programmiersprache zu lösen, bedeutet in der Regel mehr Aufwand.