In der ersten Folge der Blogserie SQL Server 2014 führe ich Sie in die Serverseitige Datenbankprogrammierung ein. In den nächsten Folgen werde ich mich dann mit dem Thema Zugriffsberechtigungen verwalten beschäftigen und runde die Serie schließlich mit den Themen Datenbank-Email und Datenbanksicherungen/Backup und Recovery ab. Sie sehen, die Blogserie wendet sich also an die Entwickler und Administratoren unter Ihnen.

Datenbankanwendungen bestehen, wie schon der Name sagt, aus einer Datenbank plus einer Anwendung. Eine Datenbank ist an und für sich schon etwas Tolles und Wichtiges, aber ohne die Anwendung in der Praxis nicht sinnvoll einsetzbar. Auch wenn aus der Sicht eines Datenbankentwicklers die Datenbank immer das Herzstück einer Anwendung ist. Sie können dies mit einem Fahrzeug vergleichen. Der Motor ist das Herzstück eines Fahrzeuges, aber dennoch würden Sie nie auf die Idee kommen, einen Motor ohne das entsprechende Chassis zu kaufen. Denn nur durch dieses wird das Ganze verwendbar. Der Motor entspricht in diesem Vergleich der Datenbank, die erst durch die Anwendung wirklich verwendbar wird.

Serverseitige Datenbankprogrammierung

Eine Datenbankanwendung besteht aus drei Ebenen: Dem Data-Layer, der für das Datenmanagement zuständig ist, dem Program-Layer, der für die Ablauflogik verantwortlich zeigt und dem Presentation-Layer, der die Aufgaben des Benutzerinterfaces übernimmt. Das Wesen einer klassischen relationalen Datenbank besteht darin, dass Zustände abgebildet werden, aber keine Abläufe. Ich möchte an einem kleinen Beispiel erläutern, was damit gemeint ist. In einer Artikeltabelle werden alle Stammdaten der Artikel eines Unternehmens gespeichert, ebenso der aktuelle Listenpreis. Wird ein Artikel verkauft, muss der tatsächliche Preis für diesen Verkauf in der Tabelle für die Rechnungspositionen gespeichert werden. Das Datenbankmodell muss daher sowohl in der Artikeltabelle als auch in der Tabelle für die Rechnungspositionen eine Spalte für den Preis vorsehen. Denn die Datenbank muss alle Zustände des Geschäftsprozesses unterstützen. Wie kommt nun aber der im Artikelstamm hinterlegte Listenpreis bei der Eingabe einer Rechnungszeile als Vorgabewert in diese Tabelle? Das interessiert die Datenbank als solche eigentlich gar nicht. Denn dies ist ein Ablauf, der im Datenmodell selber keine Berücksichtigung findet. Und finden wir uns schon an der Schnittstelle zur Anwendung wieder. Denn für Abläufe ist die Anwendung zuständig. Und wenn wir von einer Anwendung sprechen, sprechen wir auch über Programmierung. Wir befinden uns beim Program-Layer.

Vorschlag: Infokasten Komponenten der Datenbankanwendung (aus S. 2 des Buches) oder eine Abbildung dazu

  • Data Layer: Der Data Layer hat die Aufgabe, Daten zu verwalten und zu speichern. Hier werden außerdem die Strukturen der Datenspeicherung definiert. Diese Aufgabe wird von der Datenbank-Engine wahrgenommen.
  • Program Layer: Im Program Layer werden die Logiken und Abläufe des Datenzugriffs abgebildet. Hier kommen unterschiedliche Entwicklungsumgebungen zum Einsatz.
  • Presentation Layer: Aufgabe des Presentation Layers ist es, Ausgaben aus der Datenbank darzustellen. Hierzu gehören insbesondere Benutzeroberflächen und Frontend-Komponenten, mit denen der Benutzer interagiert.

 

Auf relationale Datenbanken wird mit Hilfe von SQL-Anweisungen (Structured Query Language) zugegriffen. Egal ob dies Lesezugriffe (Data Query Language) oder Schreibzugriffe sind (Data Manipulation Language), oder ob Sie die Struktur einer Datenbank erstellen (Data Definition Language) oder sich gar administrativ um die Verwaltung der Berechtigungen (Data Control Language) kümmern. Diese standardisierte Sprache (ANSI-SQL) wird einheitlich von relationalen Datenbankmanagementsystemen verwendet. Dabei handelt es sich aber noch nicht um Programmierung. SQL ist eine reine Anweisungssprache, der klassische Elemente einer Programmiersprache wie Variablen und Kontrollstrukturen fehlen. Abläufe und Logiken müssen also über eine weitere Programmiersprache implementiert werden. Dies ist je nach Aufgabenstellung mit unterschiedlichen Komponenten möglich. Dies kann einerseits im Frontend über eine Programmierung in C#, Java, PHP, ASP.NET oder ähnliches erfolgen oder aber auch direkt im Backend in der Datenbank. Dazu bieten die Hersteller unterschiedliche Erweiterungen zu SQL an, die jene Elemente ergänzen, die zu einer Programmiersprache fehlen. Beim Microsoft SQL Server ist dies die Sprache Transact-SQL, bei Oracle zum Beispiel PL/SQL. Diese bieten die Möglichkeit, über den Einsatz von Stored Prozedures, Userdefined Functions und Trigger Abläufe direkt in die Datenbank zu implementieren. Jetzt gehen moderne Ansätze oft von einer strikten Trennung von Daten und Zugriffslogik aus ­­­– ist dies nun ein Widerspruch dazu? Manche sagen daher, direkt in der Datenbank zu programmieren wäre veraltet. Wie ist dies nun zu werten? Wie bei vielen Dingen im Leben gibt es nicht nur Schwarz und Weiß, sondern auch viele Grau-Nuancen. Und hier ist es genauso.

Entscheidend wird sein, welche Art von Anwendung Sie entwickeln und welche Anwendungskomponente bei Ihnen eine Konstante darstellt. Wollen Sie eine Standardanwendung entwickeln, die ­ – um möglichst oft verkauft werden zu können – mit unterschiedlichen Datenbankmanagementsystemen verwendet werden kann, werden Sie darauf achten, alle Datenzugriffe tunlichst mit Standard-SQL-Anweisungen in einer eigenen Ebene zu definieren. Serverseitige Programmierung ist ja nicht standardisiert und die auf diese Weise umgesetzten Lösungsteile müssten für jedes unterstützte Datenbanksystem neu entwickelt werden. Dies wird in der Regel nicht zielführend und realistische sein. Daher werden Sie auf serverseitige Entwicklung in einem solchen Szenario verzichten.

Ganz anders stellt sich die Situation dar, wenn es sich bei Ihrer Anwendung um eine Individualentwicklung handelt oder das verwendete Datenbankmanagementsystem aus einem anderen Grund eine fixe Größe für Ihre Anwendung darstellt. Denn dann spielt es für Sie keine Rolle, wenn der Code auf einem anderen Datenbanksystem nicht lauffähig ist und dafür neu programmiert werden müsste. In einer solchen Situation können Sie die Vorteile, die sich durch Prozeduren, Trigger und Funktionen bieten, voll ausschöpfen. Diese wären zum Beispiel:

  • Durch systemnahe Entwicklung können Vorteile des spezifischen Datenbanksystems voll ausgeschöpft und Performancevorteile lukriert werden.
  • Datenbanken können durch indirekte Berechtigungen von Prozeduren sehr sicher gemacht werden, was insbesondere für Webapplikationen von großer praktischer Bedeutung ist.
  • Transaktionen, die sicherstellen, dass aus mehreren Schritten bestehende Schreibzugriffe in der Datenbank entweder ganz oder gar nicht ausgeführt werden, können auf keine Art so einfach und effektiv implementiert werden, wie über eine Stored Procedure.

Beim Microsoft SQL Server können Stored Procedures, Userdefined Functions und Trigger entweder über Transact-SQL oder über eine .NET-Sprache programmiert und implementiert werden. Um die Aktualität dieser Form der Entwicklung zu unterstreichen, sind die Features für die Entwicklung in den letzten Versionen des SQL Servers stets erweitert worden. Bei den neuen Speicheroptimierten Tabellen des SQL Server 2014, die zur Performancesteigerung zur Gänze im Arbeitsspeicher gehalten werden, spielen Precompiled Stored Procedures eine zentrale Rolle.

Konopasek, SQL Server 2014Wie Sie beim Einsatz des SQL Server mit Transact-SQL und .NET-Sprachen programmie­ren, welche Aufgabenstellungen sinnvoll serverseitig programmiert werden können und wo sich die Schnittstellen zur klassischen Anwendungsentwicklung befinden, lesen Sie im gerade neu erschienenen Buch SQL Server 2014. Der schnelle Einstieg. Anhand von Beispielen können Sie die serverseitige Datenbankprogrammierung mit dem SQL Server erlernen. Alle .NET-Beispiele sind durchgängig sowohl mit VB.NET als auch C# umgesetzt.

In der nächsten Folge wird es darum gehen, wie Zugriffsberechtigungen verwaltet werden können. Bleiben Sie also dabei!