# 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!