Beiträge von Tobi89

Genau das ist der Punkt – und zugleich die Kehrseite, deshalb die Frage „wann besser nicht“ 😄 Trigger haben einen ernsten Nachteil: versteckte Logik.

• Ein Trigger läuft unsichtbar mit. Wenn ein simples UPDATE plötzlich drei weitere Tabellen verändert oder einen Fehler wirft, sucht man sich beim Debuggen dumm und dämlich, weil im Anwendungscode nichts davon steht.
• Trigger, die weitere Änderungen auslösen, können Kaskaden oder sogar Endlosschleifen erzeugen, und sie kosten bei Massen-Updates Performance (sie feuern pro betroffener Zeile bzw. Anweisung).

Faustregel aus der Praxis: Trigger sind stark für datennahe, tabellenübergreifende Automatik (Historisierung, Audit-Log, Integrität, die kein Fremdschlüssel abbildet). Fachliche Geschäftslogik gehört dagegen eher in die Anwendung bzw. eine klar aufgerufene Stored Procedure, wo man sie sieht und testen kann. Sparsam einsetzen und gut dokumentieren – dann sind sie ein Segen statt einer Falle.

Und der Grund, warum es nicht ewig hängt: Das DBMS erkennt den Wartekreis aktiv (Wait-for-Graph) oder über einen Timeout und macht dann eines der beiden Opfer: es rollt eine Transaktion zurück (deadlock victim). Die bekommt einen Fehler zurück und kann einfach neu gestartet werden, die andere läuft durch.

Praxistipp gegen Deadlocks: Sperren immer in derselben Reihenfolge anfordern (z. B. immer erst die kleinere ID), Transaktionen kurz halten und nicht mehr sperren als nötig. Dann entsteht der Wartekreis gar nicht erst.

Zum „JOINs sind immer schneller“: Das ist tatsächlich ein Mythos. Bei modernen Datenbanken formt der Query-Optimizer viele Unterabfragen intern ohnehin in JOINs um – die Laufzeit ist dann gleich. Wichtiger als JOIN-vs-Subquery sind meist die Indizes auf den Verknüpfungsspalten.

Einen Fall solltest du aber kennen: die korrelierte Unterabfrage, die sich für jede Zeile der äußeren Abfrage neu ausführt – die kann bei großen Tabellen wirklich bremsen. Für „gibt es mindestens einen Treffer?“ ist EXISTS oft die sauberste und schnellste Variante, weil die Datenbank beim ersten Treffer abbricht. Und Vorsicht bei NOT IN in Kombination mit NULL-Werten – das liefert gern mal gar keine Zeilen; da ist NOT EXISTS die robustere Wahl.

Daniels Beispiel ist perfekt. Zum „Woran erkenne ich es“: Frag bei jedem Nicht-Schlüsselattribut „Brauche ich wirklich den kompletten Schlüssel, um diesen Wert eindeutig zu bestimmen?“

• Ja, den ganzen Schlüssel → bleibt in der Tabelle.
• Nein, ein Teil reicht → raus in eine eigene Tabelle (z. B. Artikel-Tabelle mit ArtikelNr + Bezeichnung).

Der praktische Grund dahinter ist die Redundanz: In der unnormalisierten Version steht die Artikelbezeichnung bei jeder Bestellung erneut. Änderst du sie mal, musst du sie überall ändern (Update-Anomalie). Nach der Aufteilung steht sie genau einmal. Genau das ist der Sinn der Übung.

Daniels Punkte sind genau die Klausur-Argumente. Zwei Ergänzungen aus der Praxis, die oft in Aufgaben abgefragt werden:

• Aktualisierbarkeit: Über eine einfache View (eine Tabelle, kein GROUP BY/DISTINCT/Aggregat) kann man teils auch schreiben (INSERT/UPDATE). Sobald Aggregationen oder mehrere Tabellen im Spiel sind, wird sie in der Regel read-only.
• Materialized View: Das ist die Ausnahme zu „speichert keine Daten“ – eine materialisierte View legt das Ergebnis physisch ab und muss aktualisiert (refreshed) werden. Vorteil: schnelle Leseabfragen bei teuren Auswertungen; Nachteil: die Daten sind nur so aktuell wie der letzte Refresh.

Merksatz fürs Verständnis: Standard-View = Abkürzung/Sichtfenster (immer aktuell), Materialized View = zwischengespeicherter Schnappschuss (schnell, aber altert).

Dem schließe ich mich an, mit einer wichtigen Ergänzung aus der Praxis: Ein Surrogatschlüssel als Primärschlüssel ersetzt nicht die fachliche Eindeutigkeit. Die bildest du zusätzlich über ein UNIQUE-Constraint auf den natürlichen Schlüssel ab.

Beispiel Student: id (Surrogat, Primärschlüssel) + matrikelnummer mit UNIQUE. So hast du beides: eine stabile ID für die Verknüpfungen und die Garantie, dass keine Matrikelnummer doppelt vergeben wird. Genau das übersehen viele in der Klausur – sie werfen den natürlichen Schlüssel ganz weg, und dann kann die Tabelle plötzlich Dubletten enthalten.

Genau, und ein super praktischer Nutzen vom LEFT JOIN: Lücken finden. Wenn du wissen willst, welche Kunden noch nie bestellt haben, machst du LEFT JOIN und filterst hinterher auf WHERE bestellung.id IS NULL – übrig bleiben genau die ohne Treffer.

Zwei Stolpersteine noch:

• Wenn ein Kunde mehrere Bestellungen hat, erscheint er bei beiden Join-Arten mehrfach – einmal pro Bestellung. Das ist normal, kein Fehler.
• Filterst du beim LEFT JOIN eine Bedingung auf die rechte Tabelle im WHERE statt im ON, wirfst du die NULL-Zeilen versehentlich wieder raus und machst den LEFT JOIN faktisch zum INNER JOIN. Bedingungen an die rechte Tabelle gehören ins ON.

Daniels Aufzählung ist komplett – ich geb dir noch die Praxis-Faustregel dazu, wann man was nimmt:

• CASCADE bei einer echten „gehört-zu“-Beziehung, wo das Kind ohne den Elternteil sinnlos ist – klassisch Rechnung → Rechnungspositionen. Löschst du die Rechnung, sollen die Positionen mitgehen.
• RESTRICT, wenn die Kind-Daten eigenständigen Wert haben und nicht versehentlich verschwinden dürfen – z. B. Kunde → Bestellungen. Da willst du eher gewarnt werden.
• SET NULL, wenn die Beziehung optional ist – z. B. Mitarbeiter → Abteilung: Wird die Abteilung aufgelöst, bleibt der Mitarbeiter bestehen, nur ohne Abteilung.

Und zur Sicherheit: Es gibt dieselben Regeln auch als ON UPDATE für den Fall, dass sich der Schlüsselwert selbst ändert. In der Praxis nimmt man aber besser unveränderliche Schlüssel (z. B. eine ID), dann spielt ON UPDATE kaum eine Rolle.

Daniel hat den Kern. Ich häng die zwei Fallen dran, die danach als Nächstes zuschlagen:

• NOT IN mit NULL: Steht in der Liste ein NULL (z. B. aus einer Unterabfrage), liefert WHERE id NOT IN (…) plötzlich gar nichts mehr, weil der Vergleich wieder auf UNKNOWN läuft.
• Ungleich vergisst NULL: WHERE rabatt <> 0 zeigt dir NICHT die NULL-Zeilen mit an – die musst du mit OR rabatt IS NULL extra dazuholen.

Praktisch ist außerdem COALESCE(rabatt, 0), wenn du NULL für eine Rechnung wie eine 0 behandeln willst. Und Randnotiz: COUNT(rabatt) zählt NULL-Werte nicht mit, COUNT(*) schon – auch eine beliebte Stolperstelle.

Ergänzend, weil in Klausuren gern gefragt: Keiner von beiden ist der „Chef“, der Aufgaben verteilt. Das Entwicklungsteam organisiert sich selbst und entscheidet, wie viel es pro Sprint schafft.

Eselsbrücke, die bei mir hängen geblieben ist: Der PO ist die Stimme des Kunden, der SM ist der Coach/Dienstleister fürs Team. Deshalb sollte man die Rollen auch nicht in einer Person bündeln – sonst würde der Termindruck vom PO die Team-Schutzfunktion des SM aushebeln.

Ergänzend der Punkt, der mir das Thema erst greifbar gemacht hat: Ein Data Warehouse ist historisiert und für Analysen aufbereitet. In der operativen DB wird der Kundenstatus überschrieben, wenn er sich ändert – im DWH bleibt die Historie erhalten, damit du „wie war der Umsatz vor zwei Jahren“ überhaupt beantworten kannst.

Der Weg von der einen in die andere Welt heißt ETL (Extract, Transform, Load): Daten aus den operativen Systemen ziehen, bereinigen/vereinheitlichen, ins Warehouse laden – meist nachts. Merksatz für die Klausur: OLTP = Tagesgeschäft (schreiben), OLAP = Entscheidungsunterstützung (auswerten).

Daniels Abgrenzung passt. Ein Detail, das in Klausuren gern abgefragt wird: DELETE und TRUNCATE unterscheiden sich auch technisch – DELETE ist DML (Data Manipulation Language, arbeitet an den Daten), TRUNCATE und DROP sind DDL (Data Definition Language, greifen an der Struktur an).

Praktische Konsequenz: TRUNCATE lässt sich in vielen Datenbanksystemen nicht so einfach zurückrollen wie ein DELETE. Faustregel fürs echte Arbeiten: Solange du dir unsicher bist, nimm DELETE mit WHERE – da kannst du vorher mit einem SELECT prüfen, was du triffst. TRUNCATE und DROP sind mächtig, aber gnadenlos. 😅

Genau so. Aus der Programmier-Sicht wird es oft noch greifbarer: Bei einer Komposition erzeugt und zerstört das Ganze seine Teile selbst (es „besitzt“ sie exklusiv). Bei einer Aggregation hält das Ganze nur eine Referenz auf ein Objekt, das woanders erzeugt wurde und geteilt werden kann.

Mein Klausur-Trick: Stell dir bei jeder Teil-Ganzes-Beziehung die Frage „Was passiert mit dem Teil, wenn ich das Ganze lösche?“ Verschwindet es zwingend → Komposition. Lebt es weiter → Aggregation. Und im Zweifel lieber eine schlichte Assoziation zeichnen: Rauten setzt man nur, wenn wirklich eine Teil-Ganzes-Semantik gemeint ist – sonst verliert man in der Klausur unnötig Punkte.

Daniels Erklärung passt. Für die „wann nimmt man was“-Frage merk dir die Faustregel über die Stabilität der Anforderungen:

• Anforderungen klar, stabil, gesetzlich/vertraglich fix (z. B. Brückenbau, Abrechnungssystem nach festem Gesetz) → Wasserfall. Planbarkeit und Dokumentation sind hier Stärken.
• Anforderungen unklar oder im Fluss, schnelles Feedback nötig (z. B. neue App, Produkt am Markt ausprobieren) → agil. Du reduzierst das Risiko, monatelang am Bedarf vorbei zu bauen.

Klassischer Klausur-Nachteil von Wasserfall: Fehler in der Analyse fallen erst ganz am Ende im Test auf und sind dann teuer. Agil fängt das früher ab, ist aber schwerer fix zu budgetieren. In der Praxis sieht man oft Mischformen.

Daniels Aufzählung deckt alles ab. Als Merkhilfe, welche Eigenschaft welches Problem verhindert:

• A verhindert halbfertige Aktionen,
• C verhindert ungültige Zustände,
• I verhindert, dass sich parallele Vorgänge gegenseitig in die Quere kommen,
• D verhindert Datenverlust nach dem Commit.

In der Praxis sorgt das DBMS dafür über Transaktionen (BEGIN … COMMIT/ROLLBACK) und ein Log. Für die Klausur reicht meist: ACID benennen, je ein Beispiel, und den Begriff Transaktion als Klammer drumherum. Das mit der Isolation wird übrigens am häufigsten unterschätzt – da hängen Themen wie Dirty Read und Locking dran, falls ihr das noch vertieft.

Und jetzt zum „warum nicht überall“ 😄 Ein Index kostet nämlich:

• Schreib-Aufwand: Bei jedem INSERT/UPDATE/DELETE muss die DB nicht nur die Tabelle, sondern auch jeden betroffenen Index aktualisieren. Viele Indizes = langsamere Schreibvorgänge.
• Speicherplatz: Jeder Index belegt zusätzlichen Platz.

Faustregel: Indiziere die Spalten, nach denen du oft filterst oder joinst, nicht jede Spalte. Bei zusammengesetzten Indizes ist außerdem die Spaltenreihenfolge wichtig (links beginnend nutzbar). Und mit EXPLAIN vor der Abfrage siehst du schwarz auf weiß, ob dein Index überhaupt verwendet wird.

Und jetzt der WHERE-vs-HAVING-Teil, das ist der Klassiker 🙂 Der Unterschied ist der Zeitpunkt der Filterung:

• WHERE filtert die einzelnen Zeilen, bevor gruppiert wird.
• HAVING filtert die fertigen Gruppen, nachdem aggregiert wurde.

Deshalb darf in HAVING eine Aggregatfunktion stehen, in WHERE nicht. Beispiel „Kunden mit mehr als 5 Bestellungen, aber nur Bestellungen aus 2026“:

• SELECT kundeID, COUNT(*) FROM bestellung WHERE jahr=2026 GROUP BY kundeID HAVING COUNT(*) > 5;

Reihenfolge der Verarbeitung merken: WHERE → GROUP BY → HAVING. Dann ist immer klar, welcher Filter wohin gehört.

Danny hat die Kernmethode genannt. Ein praktischer Zusatz für die Umsetzung in die Tabellen, weil das oft die eigentliche Klausurfrage ist:

• 1:n → der Fremdschlüssel kommt auf die n-Seite (in die Bestellung wandert die KundenID).
• n:m → braucht eine eigene Zwischen-/Beziehungstabelle, die die beiden Primärschlüssel als Fremdschlüssel aufnimmt; direkt geht es nicht.
• 1:1 → Fremdschlüssel auf einer der beiden Seiten (oft die „optionale“), manchmal werden die Tabellen sogar zusammengelegt.

Wenn du dir bei jeder Beziehung gleich mitnotierst, wohin der Fremdschlüssel wandert, hast du den Übergang vom Modell zur Datenbank schon halb erledigt.

Daniels Beispiel ist perfekt. Der eigentliche Sinn des Fremdschlüssels ist die referenzielle Integrität – und die ist der Grund, warum man ihn überhaupt als FK deklariert und nicht nur ein gleichnamiges Feld hinschreibt:

• Die Datenbank stellt sicher, dass jede KundenID in Bestellung auch wirklich in Kunde existiert. Du kannst keine Bestellung für einen Geister-Kunden anlegen.
• Sie verhindert, dass du einen Kunden löschst, der noch Bestellungen hat (oder regelt per ON DELETE, was dann passiert).

So bleiben deine Daten konsistent – keine verwaisten Datensätze. Das ist neben der Verknüpfung der zweite große Job des Fremdschlüssels. 🙂

Ergänzend ein Punkt, der in der Klausur gern abgefragt wird: Die Zwischentabelle ist auch der einzig saubere Ort für Attribute der Beziehung selbst. Note und Semester der Belegung z. B. gehören weder zum Studenten noch zum Modul, sondern genau zu dieser Kombination. Die packst du als weitere Spalten in die Zuordnungstabelle. Spätestens dann ist klar, warum es ohne dritte Tabelle nicht geht.