Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Wie Datenbanken die Architektur formen
Die Wahl der Datenbankarchitektur ist eine der wichtigsten Entscheidungen bei der Softwareentwicklung – sie beeinflusst nicht nur die technischen Implementierungsdetails, sondern prägt die gesamte Systemarchitektur. In einer aktuellen Episode von “Software-Architektur im Stream” widmet sich Eberhard Wolff dieser fundamentalen Frage und zeigt auf, wie verschiedene Datenbankansätze unsere Designentscheidungen formen.
Das Objekt-Relational-Mismatch
Der Kern des Problems liegt in der grundlegenden Diskrepanz zwischen objekt-orientierten Modellen und relationalen Datenbanksystemen. Domain-driven Design (DDD) lehrt uns, mit Aggregates, Entities und Value Objects zu denken – konzeptionellen Strukturen, die Geschäftslogik kapseln. Eine Bestellung ist beispielsweise ein Aggregate, das Bestellpositionen oder Gesamtwert mit den entsprechenden Konsistenzregeln verwaltet.
Relationale Datenbanken hingegen funktionieren völlig anders. Sie normalisieren Daten in separate Tabellen, wodurch eine einzelnes geschäftliches Objekt typischerweise mehrere Tabellen umfasst. Der Kunde lebt in der Customer-Tabelle, seine Adressen in einer separaten Address-Tabelle. Diese Normalisierung ermöglicht flexible Abfragen über Join-Operationen, führt aber zu einer fundamentalen Frage: Soll die Datenbank oder das Objekt-Modell die Architektur-Entscheidungen treiben?
Verschiedene Ansätze zur Modellierung
Martin Fowler’s “Patterns of Enterprise Application Architecture” bietet einen hilfreichen Orientierungspunkt. Das Domain Model mit Datamapper folgt dem objektorientierten Purismus – die Datenbank bleibt hinter einer Abstraktionsschicht verborgen. Beispielsweise ein OR-Mapper verwaltet die Transformation, und der Entwickler interagiert nur mit Objekten.
Das Active Record Muster, bekannt durch Ruby on Rails, geht einen anderen Weg: Eine Klasse repräsentiert eine Tabelle, enthält neben der Geschäftslogik aber auch die Persistierungslogik. Das Row Data Gateway reduziert dies noch weiter auf eine einfache Gateway-Schicht mit Objekten ohne Geschäftslogik. Table Data Gateway liefert die Daten dann in generischen Daetnstrukturen.
Bei Transaction Scripts – Prozeduren, die direkt Aktivität aus der Präsentation direkt mit Datenabnk-Querys oder Pattern wie Row Data Gateway oder Table Date Gateway umsetzen – sind Präsentation, Logik und Persistierung im Code eng verwoben. Dies mag zunächst primitiv klingen, kann aber für einfache Datenmigrationen oder CRUD-Operationen völlig ausreichend sein.
Der Preis der Flexibilität
Relationale Datenbanken bieten eine beeindruckende Flexibilität: Eine Ad-hoc-Abfrage kann spontan über viele Tabellen vom Kunden zu einzelnen Bestellpositionen navigieren und dann Umsatzdaten aggregieren, ohne dass dies vorher geplant wurde. Die Query-Optimizer sorgen dafür, dass solche Queries sogar performant sind Dies funktioniert nur, weil alle Daten auf einem Server oder Storage-System verfügbar sind, weil nur so diese unzähligen Kombinationen von Daten performant für Querys verarbeitet werden können.
Dokumentendatenbanken wie MongoDB verfolgen einen anderen Weg. Ein Aggregate wird zu einem Dokument, was die Verteilung erleichtert, aber Flexibilität kostet. Abfragen über mehrere Dokumente hinweg sind aufwendiger und schwerer zu optimieren.
Fazit
Es gibt keine universelle Antwort auf die Frage, welche Datenbankarchitektur die beste ist. Domain-driven Design passt hervorragend für komplexe geschäftliche Logik mit relationalen Datenbanken. Für Systeme mit wenig Geschäftslogik können Transaction Scripts oder einfache Gateways angemessener sein. Dokumentendatenbanken eignen sich für flexible, verteilte Systeme, opfern aber Abfrage-Flexibilität. Die Entscheidung sollte auf den konkreten Anforderungen basieren, nicht auf architektonischen Dogmen. Letztendlich formen Datenbanken unsere Architektur – daher sollten wir diese Entscheidung bewusst treffen.