Um komplexe Metriken live bei Änderungen von Daten in einem Planungstool für den Anlagenbau anzeigen zu können, wurde eine 3-schichtige Architektur mit Datenbanktriggern entwickelt. Diese löst bestehende langsame Views ab, die zu langen Ladezeiten der UI führten. Eine Trennung von Datenselektion, Businesslogik und Schreibzugriff sorgt für strukturierten Code. Ebenso sorgt die exakte Selektion der Daten, die aktualisiert werden müssen, für effiziente Trigger. Probleme bei der Wartung werden über eine strukturierte Dokumentation gelöst.

Zielpublikum: Entwickler:innen, Datenbankentwickler:innen, Software-Architekt:innen
Voraussetzungen: Datenbankgrundlagen
Schwierigkeitsgrad: Einsteiger

Extended Abstract:
Bei der Entwicklung eines Planungstools für den Anlagenbau im Rahmen eines Kundenprojekts kam die Anforderung auf, dass komplexe Metriken basierend auf den aktuell eingegebenen Daten live aktualisiert werden. Im ersten Entwicklungsschritt wurde dies mithilfe von Datenbankviews umgesetzt. Steigende Datenmengen führten dazu, dass die Antwortzeiten der UI zu langsam wurden. Eine zeitlich versetzte Aktualisierung von vorberechneten Metriken war nicht möglich.

Als Lösung wurde eine 3-schichtige Architektur mit Datenbanktriggern implementiert. Die erste Schicht besteht aus den Triggern selbst, in denen bestimmt wird, was aktualisiert werden muss. Einerseits werden die Zeilen bestimmt, die aktualisiert werden müssen. Diese werden in einer In-Memory-Tabelle gespeichert. Andererseits werden auch die Spalten/Metriken bestimmt, die sich verändert haben können. Jede Metrik wird über eine Update-Prozedur repräsentiert. Die Trigger wählen also aus, welche Prozeduren aufgerufen werden müssen und welche Zeilen aktualisiert werden sollen. Durch die exakte Auswahl dessen, was aktualisiert werden muss, wird die Effizienz der Trigger verbessert.

Die Update-Prozeduren bilden die zweite Schicht und sind alle nach dem gleichen Prinzip aufgebaut. Sie erhalten als Eingabe die In-Memory-Tabelle mit den Ids der Zeilen, die aktualisiert werden müssen. Danach rufen sie die existierenden Views auf, in denen die Businesslogik abgebildet wurde, und aktualisieren die materialisierten Metriken für die selektierten Zeilen.

Die Wiederverwendung der existierenden Views ersparte bei der Entwicklung erheblich Zeit, da die komplexe Businesslogik nicht erneut implementiert werden musste. Die Trennung der Selektion der Zeilen im Trigger, der Schreibprozeduren und der Businesslogik verhindert Code-Duplikation. Der Grund dafür ist, dass Trigger auf unterschiedlichen Tabellen mit unterschiedlichen Selektionskriterien dieselbe Update-Prozedur aufrufen können. Aufgrund der Anzahl an Metriken und der Anzahl an Tabellen, die Einfluss auf die Metriken haben, wurde eine strukturierte Dokumentation eingeführt, um die Wartbarkeit zu gewährleisten.

Es wurde eine Performanceanalyse durchgeführt, inwieweit die Trigger den Lesezugriff durch Materialisierung der Daten beschleunigen und inwieweit die Trigger den Schreibzugriff verlangsamen. Die Trigger wurden so definiert, dass sie pro Statement ausgeführt werden, um Bulkoperationen effizient zu ermöglichen, da diese im System neben Einzeloperationen auch häufig vorkommen. Es stellte sich heraus, dass die Schreibprozesse im System während der Einführung der Trigger überarbeitet werden mussten. Die Schreibprozesse waren noch nicht dahingehend optimiert, dass sie mit möglichst wenig einzelnen Schreiboperationen arbeiteten. Es mussten also Schleifen im Code mit einzelnen Updates oder Inserts in Batch-Statements umgeschrieben werden.