RoggioApp/Brainstorm/260426/17_Zeitachsen_Buchung_vs_Schicht.md

RoggioApp - Zeitachsen (Buchungen, Anwesenheit, Schichten)

Die große Vereinheitlichung

Genau wie bei den Units gibt es auch bei der Zeit keine harten Trennungen. Eine Buchung für einen Gast, eine Schicht für Personal und die private Anwesenheit eines Kollektiv-Mitglieds sind technisch absolut identisch.

Alles sind Event-Knoten auf einer Zeitachse.

Der Aufbau eines Zeitachsen-Events

Jedes dieser Ereignisse nutzt exakt dieselbe Tabelle (Event) in der Datenbank. Die Magie entsteht durch die Verknüpfung (Relationen) und das Etikett (Type).

Beispiel 1: Die klassische Gast-Buchung

• type: "RENTAL"
• startTime: 15.08.2026 15:00
• endTime: 22.08.2026 10:00
• targetUnitId: Haus A (Was ist belegt?)
• targetGroupId: Familie Rossi (Wer belegt es?)

Beispiel 2: Die Personal-Schicht (Putzen)

• type: "SHIFT_WORK"
• startTime: 22.08.2026 10:00
• endTime: 22.08.2026 14:00
• targetUnitId: Haus A (Wo wird gearbeitet?)
• targetPersonId: Putzkraft Maria (Wer arbeitet?)
• Abhängigkeit (parentEventId): Verweist auf Beispiel 1 (Wird automatisch getriggert, wenn Rossi abreist).

Beispiel 3: Anwesenheit Kollektiv (Workation/Urlaub)

• type: "PRESENCE_COLLECTIVE"
• startTime: 01.09.2026
• endTime: 14.09.2026
• targetUnitId: Zirkuswagen (Wo schläft Sev?)
• targetPersonId: Sev (Wer ist da?)

Warum das Architektur in Perfektion ist

Da alle drei Dinge in derselben Tabelle als Event mit Start- und Endzeit liegen, ist das Verhindern von Doppelbelegungen ("Clash-Detection") extrem einfach. Wenn ein Gast "Haus A" buchen will, fragt die Datenbank: "Gibt es irgendein Event (egal ob RENTAL, SHIFT oder PRESENCE), das sich mit diesem Datum auf 'Haus A' überschneidet?" Wenn Sev also für seine Workation das Haus A als "Anwesenheit" blockt, kann kein Gast es buchen. Man muss nicht drei verschiedene Tabellen (Urlaub, Buchungen, Sperrzeiten) abfragen!