Matthias K.
Datenbanken – Dort liegen doch nur Daten drin, oder? Tabellen, Spalten, Zeilen, Einträge, … Nichts was ein Excelblatt nicht auch hinbekommen würde. Oder der Notizblock am Schreibtisch, wenn’s denn wirklich sein muss.
Naja, nicht ganz. Auch wenn es vielleicht nicht das Erste ist, das einem in den Sinn kommt, wenn man „Datenbanken“ hört – die allermeisten Datenbanksysteme sind regelrechte Rechenmonster! Sie können Ihre Daten nicht nur aufnehmen, halten, und Ihnen bei Bedarf zur Verfügung stellen – sie können auch noch programmieren. Die meisten Datenbanksysteme gehen nämlich mit einer eingebauten, mehr oder weniger mächtigen Programmiersprache einher, die es Ihnen erlaubt Daten dynamisch auszulesen, einzufügen, upzudaten, und dazwischen mehr oder weniger komplexe Logiken, Fallentscheidungen und Schleifen laufen zu lassen.
Zu den gängigsten Beispielen gehören Microsofts Transact-SQL (Microsoft SQL Server), Oracles PL/SQL (Oracle Database Server) oder das quelloffene PL/pgSQL (PostgreSQL) – und einige der besonders hilfreichen Dinge, die man damit anstellen kann, stellen wir Ihnen im Folgenden vor.
Trigger
Trigger wollen getriggert werden. Von neuen Daten, geänderten Daten, gelöschten Daten, geänderten Tabellen, und mehr. Sie hängen an bestimmten Tabellen oder der gesamten Datenbank und beinhalten einen Codebatch der ausgeführt wird, wenn bestimmte festgelegte Ereignisse eintreten – wie zum Beispiel, dass neue Daten in die Tabelle eingefügt werden, bestehende Daten geändert oder gelöscht werden, oder wenn die Struktur von bestehenden Tabellen geändert oder Tabellen neu angelegt oder gelöscht werden.
In diesen Fällen wird der Code im Trigger ausgeführt. Zur Ausführungszeit stehen bestimmte Kontextinformationen zur Verfügung, wie zum Beispiel die genauen Daten die eingefügt werden sollen. Damit kann man dann sicherstellen, dass vor oder nach dem jeweiligen Ereignis auf jeden Fall bestimmte Aktionen ausgeführt werden und bestimmte Bedingungen erfüllt sind.
Functions
Functions in Datenbanksystemen folgen der gleichen Logik wie Funktionen in Programmiersprachen – sie haben Eingabeparameter, die übergeben werden müssen, wenn die Function aufgerufen wird, und geben dann fix definierbare Rückgabewerte zurück. In einem wichtigen Punkt unterscheiden sie sich jedoch: Functions in Datenbanksystemen sind nicht dafür gemacht, an anderen Stellen in anderem Code aufgerufen zu werden. Stattdessen ist es ihre Aufgabe, in SQL Statements eingebaut zu werden, um dann bei der Ausführung des Statements aufgerufen und ausgeführt zu werden.
So kann man zum Beispiel komplexe und dynamische Berechnungen für Spalten oder Datenfilterungen ausführen, ohne erst umständliche Vorberechnung vorzunehmen oder das SQL Statement allzu stark zu verkomplizieren. Sogar ganze Hilfstabellen kann man über Functions dynamisch erzeugen lassen. Je nach Struktur des SQL Statements und der Platzierung der Function wird diese dann beispielsweise einmal je Zeile oder auch nur einmal für das gesamte Statement ausgeführt.
Stored Procedures
Stored Procedures speichern Codebatches direkt in der Datenbank und ermöglichen es, diese über nur eine einzige Zeile Code ausführen zu können. Über Parameter, die ähnlich zu Functions beim Aufruf der Stored Procedure übergeben werden, können die Codebatches außerdem flexibel gehalten und dynamisch an den jeweiligen Kontext angepasst werden, der gerade benötigt wird. Der Stored Procedure kann beispielsweise eine ID des Datensatzes übergeben werden, der durch den Codebatch bearbeitet werden soll, oder Optionen für verschiedene Ausführungsmodi.
So ist es möglich, direkt über das Datenbanksystem komplexe Verarbeitungsschritte abzuwickeln, für die man andernfalls separate Programmierumgebungen und Codebatches benötigen würde, während man gleichzeitig direkten und uneingeschränkten Zugriff auf die Datenbank hat. Auch das Starten externern Programme und die Verbindung zu anderen Datenbanken ist so möglich, was die möglichen Einsatzgebiete von Stored Procedures schier unendlich macht.
Wann nimmt man was?
Trigger, Functions, Stored Procedures – jedes für sich bietet unzählige Möglichkeiten, Automatisierung bis in Ihre Datenbank zu bringen. Alle 3 Optionen gleichzeitig können einen da schon schnell vor ein Entscheidungsdilemma stellen. Wann nimmt man denn was? Wie kann man sich da festlegen?
Klare Regeln gibt’s dabei natürlich nicht. Jede Option bietet umfangreiche Möglichkeiten, Code auf der Datenbank auszuführen. Der Fantasie des Datenbankprogrammierers sind kaum Grenzen gesetzt – wenn das gesetzte Ziel erreicht wird, war die gewählte Methode die richtige. Einige Best Practices gibt es aber doch, an denen man sich im Zweifel orientieren kann:
- Da Trigger direkt an einzelnen Tabellen hängen und bei jeglicher Änderung an Daten eingehängt werden können, werden sie häufig dazu benutzt, komplexe Konsistenzkriterien oder Konsistenzkriterien über mehrere Datenbanken hinweg zu forcieren
- Functions eignen sich durch den strikt definierbaren Rückgabewert und die Art, wie sie in SQL Statements eingebunden werden können am besten dafür, mathematisch komplexe Berechnungen für Datenbankabfragen durchzuführen oder komplexe Datenbeziehungen zu abstrahieren
- Über Stored Procedures werden häufig organisatorische Prozesse automatisiert, für die andernfalls ein Techniker händische Arbeitsschritte in der Datenbank starten müsste. Zum Beispiel kann so die Verarbeitung von Daten angestoßen und der Verarbeitungsstatus direkt in der Datenbank protokolliert werden, oder automatisiert Mails verschickt werden, wenn bestimmte Bedingungen eintreten
Fazit
Unterschätzen Sie Ihre Datenbank nicht – sie kann mehr als Sie denken! Die in den Datenbanksystemen integrierten Programmiersprachen bieten vielfältige Möglichkeiten, Automatisierungstasks rund um Ihre Daten zu realisieren, ohne dabei umständlich auf externe Systeme und Programmiersprachen zurückgreifen zu müssen.
Lassen Sie uns gemeinsam Automatisierung in Ihre Datenhaltung bringen und das Beste aus Ihrer Datenbank und Ihrer Zeit herausholen! Kontaktieren Sie uns hier.
