Diagnoseaufgabe

Die Standortbestimmung ist eine Lernaufgabe, keine Falle. Sie zeigt, welche Grundlagen du sicher abrufen kannst und wo du in den nächsten Blöcken aufmerksam sein solltest.

Teil 1: Schema lesen¶

Erkläre mit eigenen Worten:

• Warum tickets.team_id verpflichtend ist.

• Warum tickets.assigned_to_id optional ist.

• Warum ticket_labels einen zusammengesetzten Primärschlüssel hat.

• Welche Daten beim Anzeigen einer Ticket-Liste wahrscheinlich gebraucht werden.

Teil 2: SQL korrigieren¶

Eine fehlerhafte Query ist ein realistisches Arbeitsmittel. In Projekten liest du oft bestehenden Code und musst entscheiden, ob er fachlich korrekt ist.

Typische Fragen:

• Fehlt eine Join-Bedingung?

• Werden optionale Beziehungen versehentlich ausgeschlossen?

• Wird vor oder nach der Gruppierung gefiltert?

• Ist die Query für den späteren API-Fall verständlich?

Teil 3: Transaktion skizzieren¶

Beim Erstellen eines Tickets sollen drei Operationen zusammengehören:

1. Ticket speichern

2. ersten Kommentar speichern

3. Event created speichern

Wenn Schritt 2 fehlschlägt, muss Schritt 1 zurückgerollt werden. Sonst entsteht ein Ticket ohne Startkommunikation und ohne vollständigen Verlauf. Das ist kein SQL-Detail, sondern eine fachliche Konsistenzregel.

Teil 4: Zugriffstechnik einordnen¶

Nicht jeder Datenzugriff braucht dieselbe Technik:

Die genaue Entscheidung hängt vom Projekt ab. Wichtig ist, dass du sie begründen kannst.