Logik in der Datenbank

Was ist eine Stored Procedure?

gespeicherte Prozedur

Eine Stored Procedure ist ein benanntes Programm, das in der Datenbank gespeichert und dort ausgeführt wird, Parameter entgegennimmt und mehrere SQL-Anweisungen samt Ablauflogik zu einem einzigen Aufruf zusammenfasst.

Wenn dieselbe Auswertung aus drei Anwendungen heraus gebraucht wird, stellt sich die Frage, ob die Logik dreimal im Code steht oder einmal in der Datenbank.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Liegt: Im Datenbankschema, nicht im Anwendungscode
Aufruf: CALL beziehungsweise EXEC mit Parametern
Typisch bei: Nachtläufen und Massenverarbeitung
Verwechselt mit: Function, Trigger und View

Aufbau und Aufruf

In Oracle schreibst du Prozeduren in PL/SQL. Der Kopf legt Namen und Parameter fest, jeweils mit Richtung: IN für Eingaben, OUT für Rückgaben, IN OUT für beides. Im Rumpf stehen SQL-Anweisungen, Variablen, Schleifen, Bedingungen und die Fehlerbehandlung im EXCEPTION-Block.

Aufgerufen wird sie aus einem Datenbankwerkzeug, aus einem Job oder aus der Anwendung, in Java etwa über ein CallableStatement. Mehrere zusammengehörige Prozeduren fasst Oracle in einem Package zusammen: Der Kopf zeigt nach außen, was aufrufbar ist, der Body enthält die Umsetzung und lässt sich ändern, ohne dass abhängige Objekte ungültig werden.

Wofür sich das im Betrieb lohnt

Der stärkste Grund ist Datennähe. Eine Verarbeitung, die viele Zeilen liest, prüft und in eine andere Tabelle schreibt, muss die Daten nicht über das Netz zur Anwendung und zurück tragen. Was in der Anwendung Minuten dauert, ist in der Datenbank oft eine Sache von Sekunden.

Der zweite Grund sind Rechte. Du kannst einem Konto das Ausführen einer Prozedur erlauben, ohne ihm Zugriff auf die zugrundeliegenden Tabellen zu geben. Damit wird die Prozedur zur einzigen Tür, und diese Tür ist prüfbar. Für Verfahren mit strengen Vorgaben ist das häufig der ausschlaggebende Punkt.

Dazu kommt, dass mehrere Anwendungen dieselbe Regel benutzen können. Wenn eine Bestandsbuchung von drei Programmen und zwei Importen ausgelöst wird, gibt es die Regel in der Datenbank genau einmal statt fünfmal.

Wo es schwierig wird

Logik in der Datenbank landet oft außerhalb der Versionsverwaltung. Wenn eine Prozedur nur im Produktivsystem existiert, weiß niemand, wer sie wann geändert hat. Der Ausweg ist, den Quelltext genauso im Repository zu führen wie den Anwendungscode und über Migrationsskripte einzuspielen.

Testen und Fehlersuche sind mühsamer als in der Anwendung, und es gibt weniger Werkzeuge dafür. Außerdem bindest du dich an das Datenbanksystem: PL/SQL läuft nicht auf einem anderen Hersteller, ein Wechsel bedeutet Neuschreiben.

Die brauchbare Faustregel: Mengenverarbeitung und Regeln, die die Datenintegrität sichern, sind in der Datenbank gut aufgehoben. Fachliche Abläufe, die sich häufig ändern, gehören in die Anwendung, wo sie versioniert, getestet und im Team gelesen werden.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Stored Procedure und was oft damit gleichgesetzt wird

Stored Procedure gegen Function

Eine Funktion gibt einen Wert zurück und darf deshalb in SQL-Ausdrücken stehen, etwa in einer SELECT-Liste oder einer WHERE-Bedingung. Eine Prozedur wird als eigene Anweisung aufgerufen und gibt Werte über OUT-Parameter zurück.

Stored Procedure gegen Trigger

Ein Trigger wird nicht aufgerufen, sondern feuert automatisch bei INSERT, UPDATE oder DELETE. Das ist mächtig und unübersichtlich: Wer einen Fehler sucht, sieht im Anwendungscode nicht, dass beim Speichern noch etwas anderes passiert.

Stored Procedure gegen View

Eine View ist eine gespeicherte Abfrage ohne Ablauflogik und ohne Parameter. Wenn du nur eine wiederkehrende Sicht auf Daten brauchst, ist sie die einfachere Wahl.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Nah an den Daten ist schnell, aber schwer im Griff zu behalten

Der Fall, in dem sich das eindeutig lohnt, ist der Mengenjob: Ein Lauf liest große Bestände, verdichtet sie und schreibt das Ergebnis zurück. Steckt die Logik in der Anwendung, wandert jede Zeile über das Netz und wieder zurück. In der Datenbank bleibt sie, wo sie liegt, und der Aufruf schrumpft auf einen Befehl mit Parametern.

Der Preis zeigt sich beim Ausrollen. Prozeduren leben im Schema und nicht im Repository, und sie werden gern direkt auf dem Server geändert, wenn es eilt. Dann steht in der Versionsverwaltung eine Fassung und auf dem Produktivsystem eine andere. Wer Prozeduren einsetzt, braucht deshalb Migrationsskripte, die denselben Weg über Freigabe und Auslieferung nehmen wie der übrige Code.

Dazu kommt die Bindung an das Produkt. T-SQL, PL/SQL und PL/pgSQL sind verschiedene Sprachen, und was in der Prozedurschicht steckt, wandert bei einem Wechsel des Datenbanksystems nicht mit. Für Fachlogik, die sich häufig ändert, ist das ein schlechter Ort, für datennahe Operationen mit klarer Schnittstelle ein guter.

Stored Procedure lernen

Wie Packages, Cursor und Fehlerbehandlung in PL/SQL zusammenspielen, zeigen die Oracle-Trainings für Entwicklung und Betrieb an konkreten Aufgaben.

Wie andere Systeme dasselbe Problem lösen, vergleichst du in den herstellerübergreifenden Datenbankkursen .

Kurse, die Stored Procedure behandeln

Häufige Fragen

Schützen Stored Procedures vor SQL-Injection?

Nicht von allein. Der Schutz kommt von gebundenen Parametern, und den bekommst du auch mit gewöhnlichen Abfragen. Wenn innerhalb der Prozedur mit EXECUTE IMMEDIATE ein String zusammengebaut wird, ist die Lücke genauso da.

Gehört Geschäftslogik in die Datenbank?

Das hängt davon ab, wie viele Wege es zu den Daten gibt. Schreiben mehrere Anwendungen und Importe auf dieselben Tabellen, ist die Datenbank der einzige Ort, an dem eine Regel wirklich für alle gilt. Bei genau einer Anwendung ist der Anwendungscode meist besser zu pflegen.

Wie bekomme ich Prozeduren in eine Deployment-Pipeline?

Indem du sie als Dateien im Repository hältst und über ein Migrationswerkzeug einspielst, das jede Änderung als eigenen Schritt festhält. Ein Abgleich des Datenbankstands gegen das Repository im Test deckt auf, wenn jemand direkt am System geschraubt hat.

Persönlich für dich da