Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

In Relational Databases hast du viele Grundlagen kennengelernt. Für Database Development sind nicht alle gleich wichtig. Entscheidend ist, ob du sie in einer Anwendungssituation wiedererkennst.

Stell dir vor, ein API-Endpunkt soll alle offenen Tickets eines Teams anzeigen. Schon diese scheinbar einfache Anforderung berührt mehrere Themen aus Relational Databases:

SQL als gemeinsame Sprache

Auch wenn spätere Blöcke mit Spring Data JPA und Hibernate arbeiten, bleibt SQL die gemeinsame Sprache zwischen Anwendung und Datenbank. Ein Repository kann dir Schreibarbeit abnehmen. Es nimmt dir aber nicht die Verantwortung ab, Datenzugriffe zu verstehen.

Besonders wichtig bleiben:

Modellierung als Architekturentscheidung

Eine Datenbankstruktur ist nicht nur eine technische Ablageform. Sie prägt, wie Anwendungscode aussieht. Eine falsch modellierte n:m-Beziehung führt später zu umständlichen Queries, komplizierten DTOs oder fehleranfälliger Geschäftslogik.

Im Ticket-System ist die Beziehung zwischen Tickets und Labels ein gutes Beispiel. Ein Ticket kann mehrere Labels haben, und ein Label kann zu vielen Tickets gehören. Deshalb braucht es eine Zwischentabelle ticket_labels. Ein Textfeld mit kommagetrennten Labels wäre schneller hingeschrieben, aber schlechter abfragbar, schwerer validierbar und weniger robust.

Transaktionen als Schutz fachlicher Abläufe

Transaktionen werden in Database Development aus Anwendungssicht betrachtet. Du fragst nicht nur: “Was ist ACID?”, sondern:

Welche Schritte müssen gemeinsam erfolgreich sein, damit der fachliche Zustand korrekt bleibt?

Beim Erstellen eines Tickets gehören beispielsweise Ticket, erster Kommentar und Ereigniseintrag zusammen. Wenn der Kommentar fehlschlägt, soll nicht trotzdem ein halbfertiges Ticket übrig bleiben.

Genau hier wird später @Transactional im Service-Layer wichtig.