Block 1 endet dort, wo Database Development richtig beginnt: bei der Frage, wie Datenbankentscheidungen im Anwendungscode sichtbar werden.
Vom SQL-Schema zur Anwendung¶
In einer Spring-Boot-Anwendung treffen mehrere Schichten aufeinander:
Der Controller nimmt Anfragen entgegen. Der Service enthält fachliche Abläufe und Transaktionsgrenzen. Das Repository kapselt den Datenzugriff. PostgreSQL erzwingt Constraints und speichert den Zustand dauerhaft.
Diese Schichten sind nicht einfach Ordner im Projekt. Sie verteilen Verantwortung.
ORM hilft, ersetzt aber kein Verständnis¶
Hibernate/JPA kann Entities auf Tabellen abbilden, Beziehungen laden und SQL generieren. Das ist produktiv und in vielen Anwendungen sinnvoll. Gleichzeitig entstehen typische Fragen:
Wird eine Beziehung zu früh oder zu spät geladen?
Entsteht ein N+1-Problem?
Passt die Entity-Struktur zur API?
Ist eine Query als Repository Method noch lesbar?
Braucht ein Reporting-Fall natives SQL?
Database Development trainiert genau diese Entscheidungen.
Migrationen statt zufälliger Schemaänderungen¶
Im Unterricht wird das Ticket-Schema zuerst als SQL-Schema sichtbar. Später wird es mit Flyway versioniert. Damit wird eine wichtige professionelle Regel eingeführt:
Das Datenbankschema entwickelt sich kontrolliert mit der Anwendung.
Eine Spalte hinzuzufügen ist einfach. Schwieriger ist die Frage, was mit bestehenden Daten passiert, wann Constraints aktiviert werden und wie ein Team die Änderung nachvollziehen kann.
Transaktionsgrenzen gehören in den Service¶
In Relational Databases hast du Transaktionen als Datenbankkonzept kennengelernt. In Database Development wird daraus eine Architekturentscheidung:
@Transactional
public TicketDto createTicket(CreateTicketRequest request) {
// Ticket speichern
// ersten Kommentar speichern
// Event schreiben
// bei Fehler: Rollback
}Die Annotation ist nur die technische Oberfläche. Entscheidend ist die fachliche Frage: Welche Zustandsänderungen gehören untrennbar zusammen?