Clara Zetkin
47 lines
3.1 KiB
Markdown
Executable File
47 lines
3.1 KiB
Markdown
Executable File
# 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.
|