# RoggioApp - Die Ultimative Abstraktion (Einheiten & Eigenschaften)

## 1. Die physische Welt ist ein Graph aus "Einheiten" (Units)
Es gibt keine festen, harten Tabellen wie `Wohnungen`, `Räume` oder `Parkplätze`.
Alles ist eine grundlegende **Unit** (Einheit) auf dem Gelände.

### Was definiert eine Unit?
Eine Unit ist lediglich ein Knotenpunkt (Node), der über seine Eigenschaften (Properties/Traits) und seine Verbindungen (Parent/Child) definiert wird.

**Beispiele für Einheiten (Units):**
*   Das Grundstück selbst (Unit)
*   Das Haus A (Unit, liegt auf dem Grundstück)
*   Ein Zirkuswagen (Unit)
*   Ein Badezimmer (Unit, liegt in Haus A)
*   Ein Stück Rasen (Unit)

### Die Eigenschaften (Traits / Properties)
Was die Unit *ist* oder was man mit ihr *tun* kann, wird über zugewiesene Eigenschaften bestimmt:
*   `is_rentable` (RentalUnit): Die Einheit kann gebucht werden (z.B. Wohnung, Zirkuswagen, Veranstaltungsraum, Parkplatz).
*   `needs_service` (Serviceable): Die Einheit erfordert Reinigung oder Instandhaltung (gilt für Mietobjekte, aber eben auch für Flure oder den privaten Putzraum).
*   `has_capacity` (Capacity): Definiert, wie viele Schlafplätze (oder Sitzplätze beim Veranstaltungsraum) sich durch die Untereinheiten ergeben.

## 2. Die Akteure (Personen & Gruppen)
Auch hier wird stark normalisiert, um Doppelungen bei den Personendaten zu vermeiden (z.B. wenn Peter dieses Jahr mit Familie A kommt und nächstes Jahr mit Verein B).

*   **Person (Die Basis):**
    *   *Eindeutig / Fest:* Vorname, Nachname, Geburtsdatum, Ausweisnr., Mail, Mobil, Foto.
    *   *Kategorisierung (Eigenschaft):* Ist diese Person Kollektiv-Mitglied, Support-Gang, Personal oder Gast/Kunde? (Kann sich überlappen!).
*   **Adresse (Die Location):**
    *   *Nicht eindeutig / Shared:* Straße, Hausnummer, PLZ, Stadt, Land. (Mehrere Personen können dieselbe Adresse referenzieren).
*   **Gruppe (Die Entität, die bucht):**
    *   Besteht aus $N$ Personen.
    *   *Variabel:* Person X kann Mitglied in Gruppe A (Familienurlaub) und Gruppe B (Yoga-Retreat) sein.

## 3. Die Transaktionen (Buchungen & Aktionen)
*   **Buchungen (Bookings):**
    *   Verbinden eine **Gruppe** mit einer **RentalUnit** (Unit mit `is_rentable=true`) über einen bestimmten Zeitraum.
*   **Aktionen (Tasks / Operations):**
    *   Putzen, Einkaufen, Abholen.
    *   Können an eine Buchung geknüpft sein (Endreinigung nach Gruppe A).
    *   Oder an eine Unit (Grundreinigung des Flurs, der `needs_service` ist, aber nicht `is_rentable`).

## Claras architektonische Ableitung
Das ist ein Entity-Component-System (ECS) oder ein Node-Graph, wie man ihn aus Game-Engines oder extrem skalierbaren ERP-Systemen kennt! 
Statt 20 verschiedener Tabellen (`flats`, `rooms`, `parking_spaces`) bauen wir einen großen `units`-Baum. Was die Unit kann, bestimmt eine Verknüpfungstabelle `unit_traits`. 
Das macht das System zukunftssicher: Wenn ihr morgen beschließt, Surfbretter zu verleihen, legt ihr einfach neue Units an, gebt ihnen den Trait `is_rentable` (RentalUnit) und sie tauchen sofort im Buchungskalender auf, ohne dass das Datenbankschema geändert werden muss.