Inhalt
Um vollständig zu verstehen, warum und wo PL/SQL die richtige Wahl ist, ist es wichtig, die Einschränkungen anderer Alternativen zu betrachten. Gehen wir also zurück in der Zeit und schauen wir uns an, warum PL/SQL überhaupt existiert.
Ich möchte lieber eine “echte” Sprache nutzen
Vor PL/SQL war die einzige Möglichkeit, SQL Befehle innerhalb eines prozeduralen Programms zu nutzen, die SQL Befehle einzubetten (embedding). Dies war notwendig, weil SQL keine Möglichkeiten kennt, Regeln zu etablieren wie „Wenn ein Artikel verkauft ist, erhöhe die Monatsverkäufe um eins und mindere den Artikelbestand um eins“ oder „Nur Personen, die Manager sind, dürfen das Gehalt um mehr als 10 Prozent erhöhen“. Also brauchte man bspw. C-Programme, um diese Geschäftslogik zu implementieren. Während diese “Host-Sprachen” wie C mehr oder minder gut funktionieren (nämlich solange, wie ausschließlich die Applikation eingesetzt wird, und das ist eine wichtige Voraussetzung!), gibt es einige Einschränkungen: C-Compiler und Bibliotheken verschiedener Hersteller sind nicht 100% kompatibel, was es teuer macht, von einer Plattform auf eine andere zu portieren. Selbst, wenn der Code sich nicht verändert, muß man dennoch testen. Weil ORACLE sein PL/SQL so designed hat, daß es auf jeder Plattform läuft, sind Stored Procedures auf verschiedener Server-Hardware und Betriebssystemen wiederverwendbar mit keinem bis geringem Testaufwand. Dies ist nicht nur wichtig für Softwarehersteller, sondern auch für ORACLE selbst, macht es dies doch einfacher, neue Features auf über 80 verschiedenen Plattformen, auf denen ORACLE läuft, zu entwickeln (Eine der Werbeaussagen von ORACLE war langezeit „running everywhere“). Trot vieler Erweiterungen ist die Sprache C eher für andere Anwendungen gedacht als für typische Geschäftsanwendungen. Entwickler werden hier nicht die C-Pointer nutzen und Zeichenkettenverarbeitung ist eher schwieriger als in PL/SQL. Als ORACLE begann, sich auszubreiten, sah die Industrie schnell den Segen in der Verlagerung der Geschäftsprozesslogik auf die Datenbankseite, um unabhängig von der Front-End-Applikation zu werden, mit der auf die Daten zugegriffen wird. Ein C-Programm wird immer außerhalb der Datenbank ausgeführt werden müssen, es kann nicht verwendet werden, um eine „echte“ stored procedure bereitzustellen.
Warum überhaupt Stored Procedures nutzen?
Obwohl es viele Gründe für den Einsatz von Stored Procedures gibt, haben sich diese im Laufe der Zeit verändert. Als Stored Procedures neu waren, hatte man nur zwei Möglichkeiten, Applikationslogik unterzubringen: Entweder auf der Client-Seite, normalerweise ein PC, oder auf der Datenbankserver-Seite. Man hat hier häufig für die Datenbankseite argumentiert mit Hinweisen auf die Zentralisierung von komplexem Code, Sicherung der Datenbank, Wiederverwendbarkeit der Software und erhöhter Performance.
Heutzutage läuft häufig eine Mittelschicht zwischen Client und Datenbank, z.B. ein Webserver. Diese Mittelschicht enthält für gewöhnlich die Applikationslogik. Auch hier gibt es jedoch Gründe, sich für den Einsatz von Stored Procedures zu entscheiden:
Weniger Verteilung notwendig
Verläßt man sich auf den Einsatz von Stored Procedures, gibt es weniger notwendige Verteilung über das Gesamtsystem. Entwicklungsleistung über drei Schichten (Client, Mittelschicht und Server) ist meist schwerer zu koordinieren und daher teurer. Außerdem ist die Erweiterungen eines Systems mit weniger Komponenten einfacher und günstiger. Zentralisierte Konsistenz Stored procedures geben mehr Sicherheit in der Datenintegrität. Es ist einfacher, nicht Sicherheit sowohl in der Datenbank als auch in der Mittelschicht implementieren zu müssen. Der Ausdruck „Sicherheit“ meint hier sowohl Privilegien (OTTO darf auf die Buchhaltungstabelle zugreifen) wie auch Geschäftsprozesse (es dürfen nur Buchungen der letzten 30 Tage verändert werden).
Performance
Stored procedures können die Performanz des Gesamtsystems erhöhen.
Produktivität der Entwicklung
Stored procedures können zu erhöhter Produktivität bei der Softwareentwicklung führen. Wenn bspw. Produkte entwickelt werden, die die Existenz von Tabellen (und damit von einer Datenbank) voraussetzen. Beispielsweise kann innerhalb von ORACLE mit PL/SQL Programme geschrieben werden, die DML-Operationen über Views möglich machen (was sonst nur unter bestimmten Bedingungen geht). Nun aber endlich zum grundlegenden Aufbau von PL/SQL.