Zum Inhalt springen
  • Von: Christian Schwitalla
  • Datenbank PL/SQL Development
  • 06.02.2019

Das Pink-Database-Paradigma (PinkDB): Die Datenbank durch die rosa Brille

Christian Schwitalla, Stellvertretender Leiter der Development Community, hat mit Philipp Salvisberg (Trivadis) über dessen PinkDB-Ansatz gesprochen.

Philipp, datenbankzentrierte Softwareentwicklung gehört zu Deinen Schwerpunkten. In Deinem Blog beschreibst du PinkDB als "application architecture for database centric applications". Könntest du die wesentlichen Eigenschaften des PinkDB-Ansatzes beschreiben?

„PinkDB“ steht für „processing in knowing database“. Im Kern geht es darum, die Verarbeitung zu den Daten zu bringen und nicht umgekehrt. Wenn die Daten also in einer relationalen Datenbank gespeichert sind, bringen wird die Verarbeitung im ersten Schritt dorthin. Wir beschreiben mit möglichst wenigen SQL-Befehlen, was zu tun ist und überlassen das Wie – die Auswahl der geeigneten Algorithmen – der Datenbank. Der Optimizer findet heutzutage in den allermeisten Fällen gute Lösungen. Falls nicht, können wir ihm immer noch helfen. Der Zugriff auf die Tabellen wird über eine API geschützt. Eine API besteht aus Views und Stored Objects. Dadurch schaffen wir den Spielraum, Datenmodelle und APIs weitgehend unabhängig voneinander zu erweitern. Der Zugriff auf die APIs erfolgt über sogenannte Connect-User, welche nur für APIs berechtigt sind und keine eigenen Objekte besitzen.

Wo liegt der Unterschied zu anderen Konzepten, wie zum Beispiel der SmartDB von Bryn Llewellyn?

PinkDB ist nichts Neues und beschreibt, was wir in den 90er Jahren unter „Thick Database“ verstanden haben. SmartDB ist eine extreme Form von PinkDB. Ein SmartDB API besteht ausschließlich aus PL/SQL Packages. Ausserdem dürfen Transaction Control Statements (COMMIT, ROLLBACK, etc.) nur innerhalb von PL/SQL Packages ausgeführt werden. Im Gegensatz zu Entity Microservices nutzen SmartDB und PinkDB Applikationen die Datenbank als Processing Engine. Dies reduziert Network Roundtrips, den Ressourcenverbrauch auf der Datenbankseite und die Verarbeitungszeiten. Dadurch, dass Views in einer API einer SmartDB Applikation nicht erlaubt sind, ist das sinnvolle Einsatzgebiet kleiner als bei einer „klassischen“ PinkDB Applikation. Views sind für mich ein wesentliches Element einer Datenbank API, um Konsumenten wie APEX die Möglichkeiten von SQL zur Verfügung zu stellen.

Bei Datenbanken denkt man eher an Datenmodellierung. Warum sollte man beim Aufbau einer Datenbank auch die Applikationsarchitektur im Blick behalten?

Die Datenmodellierung ist nach wie vor ein zentraler Aspekt bei Datenbanken. Sich Gedanken über die API einer Datenbank zu machen, hilft bei der Wartung und Weiterentwicklung einer Applikation. Solange sich die bestehenden API-Komponenten nicht anders verhalten, können jederzeit neue Versionen der Datenbank-Komponenten freigegeben werden, ohne dass die entsprechenden Konsumenten (Middle-Tier, GUI) angepasst werden müssen. Das hilft beim Fixen von Bugs aber auch bei der Einführung von neuer, geänderter Funktionalität mit Hilfe von versionierten API-Komponenten. In Zeiten immer kürzer werdender Release-Zyklen ist dies ein nicht zu unterschätzender Mehrwert.

Im Rahmen deiner beruflichen Tätigkeit bist Du häufig in Kundenprojekten unterwegs. Machen sich die Datenbank-Anwender ausreichend Gedanken über Applikationsarchitektur?

Es kommt darauf an. Auf den Kunden, die Aufgeschlossenheit der Architekten und das Vorhaben. In den letzten Jahren war schon ein Trend weg von der Datenbank festzustellen, was teilweise zu unglaublich ineffizienten Lösungen geführt hat. Datenbanken als dummen Datenspeicher einzusetzen, führt zu mehr Netzwerkverkehr, höherem Ressourcen-Verbrauch in der Datenbank und schlechteren Verarbeitungszeiten. Mein Eindruck ist, dass dies in letzter Zeit mehr und mehr verstanden wird und die Akzeptanz von datenbanknahen Architekturen wieder gestiegen ist.

Bietet die Projektpraxis ausreichend Raum für Gedanken an neue Lösungen, wie zum Beispiel PinkDB? Wie flexibel kann dieser Ansatz ausgelegt werden?

PinkDB ist ein praxisnahes Paradigma. Es besteht aus vier Empfehlungen, welche einfach zu befolgen sind. PinkDB erlaubt auch Ausnahmen, solange die Gründe dafür dokumentiert werden. Damit ist ein hoher Grad an Flexibilität gegeben.

Wurde PinkDB bereits in Kundenprojekten umgesetzt? Welche Erfahrungen hast Du dabei gemacht?

Ja. ThinkDB oder FatDB gibt es schon lange. Wir haben es in vielen Projekten erfolgreich eingesetzt. Als problematisch habe ich in diesen Projekten hauptsächlich den Einsatz von komplexen oder geschachtelten Instead-of-Triggern in Erinnerung. Vor allem dann, wenn viele Datensätze verarbeitet wurden. Heute achte ich beim Design auf die Notwendigkeit von zusätzlichen, bulk-fähigen APIs.

Im Gegensatz zu früheren Trends kann man zunehmend Bestrebungen beobachten, die datenintensive Anwendungen wieder nah an den Daten zu platzieren. Unterstützt der PinkDB-Ansatz diesen Trend?

Auf jeden Fall. Verarbeitungen nahe an der Datenbank auszuführen, ist ein wesentliches Ziel von PinkDB. Auch wenn in Diskussionen immer wieder die View API gestresst wird, darf man nicht vergessen, dass PinkDB explizit auch Stored Objects, das heißt Packages, Object Types, Functions und Procedures als Teil der API unterstützt. Damit lassen sich beispielsweise Batch-Verarbeitungen in der Datenbank optimal umsetzen.

Denkst Du, dass der PinkDB-Ansatz weiterentwickelt werden kann? Gibt es weitere Ansätze, die Du interessant findest?

Ja, ich denke die PinkDB-Empfehlungen lassen sich konkretisieren. Beispielsweise wie genau APIs versioniert werden können, welche Vor- und Nachteile der jeweilige Ansatz hat und welche Rolle EBR dabei spielen kann. Interessant finde ich die aktuellen Entwicklungen betreffend der MLE. Nicht nur wegen der zusätzlich zur Verfügung stehenden Sprachen in der Datenbank und deren effiziente Interoperabilität, sondern auch betreffend der Möglichkeit, Verarbeitungen zur Laufzeit transparent vom Middle-Tier zur Datenbank zu verschieben.

Danke für das Interview!