Init: RoggioApp Architecture, Prisma Schema, API MVP

2026-04-26 19:42:42 +02:00
commit 193b29e8a9
5256 changed files with 1446953 additions and 0 deletions
@@ -0,0 +1,25 @@
+# RoggioApp - Datenarchitektur & Normalisierung
+
+## 1. Die Grundphilosophie (Single Source of Truth)
+*   **Keine Redundanz:** Keine doppelte Datenhaltung und (noch wichtiger) keine doppelte Dateneingabe.
+*   **Ableitung statt Hardcoding (Computed Values):**
+    *   Die Fläche einer Wohnung wird *nicht* als eigenes Feld in der Datenbank eingetragen. Sie wird berechnet (Summe der Flächen aller Räume, die zur Wohnung gehören).
+    *   Die Schlafplatzkapazität einer Einheit wird *nicht* als Zahl eingetragen. Sie ergibt sich aus: `Einheit -> hat Räume (Kategorie: Schlafzimmer) -> hat Betten -> Bett hat Schlafplätze (1 oder 2) = Summe X`.
+
+## 2. Granularität & Hierarchie
+Alles im physischen Raum ist eine "Unit" (Einheit), die zueinander in Beziehung steht und strikt kategorisiert sein muss.
+
+**Beispiel-Hierarchie für Kapazitäten:**
+1.  **Unit: Wohnung** (z.B. Haus A, Wohnung 1)
+2.  --> besteht aus **Unit: Raum** (z.B. Zimmer 1, Kategorie: Schlafzimmer)
+3.  ----> enthält **Inventar/Unit: Bett** (Kategorie: Doppelbett, Kapazität: 2 Personen)
+4.  --> besteht aus **Unit: Raum** (z.B. Zimmer 2, Kategorie: Schlafzimmer)
+5.  ----> enthält **Inventar/Unit: Bett** (Kategorie: Einzelbett, Kapazität: 1 Person)
+
+*Ergebnis:* Das System weiß automatisch, dass die Wohnung 3 Schlafplätze hat. Wenn ein Einzelbett ins Zimmer gestellt wird, erhöht sich die Kapazität der Wohnung automatisch auf 4, ohne dass jemand das Datenfeld "Wohnung_MaxPax" ändern muss.
+
+## Claras Architektonische Ableitung
+Diese Anforderung schreit nach einem strikten, relationalen Baum-Modell (Tree/Graph) in PostgreSQL.
+*   *Vorteil:* Absolute Konsistenz. Es gibt keine Widersprüche (z.B. "Wohnung hat 5 Betten, aber im System steht Kapazität 2").
+*   *Herausforderung (auf die wir achten müssen):* Solche "Bottom-Up"-Berechnungen (Summen aus der Tiefe der Datenbank holen) können in SQL sehr komplex (viele JOINs) werden, wenn man z.B. nur schnell filtern will: "Zeig mir alle Wohnungen für 4 Personen". 
+*   *Lösungansatz:* Wir nutzen das normalisierte Modell für die *Struktur*, aber arbeiten beim Abfragen vielleicht mit Datenbank-Views (Materialized Views) oder Prisma-Computed-Fields, damit das Frontend nicht endlos rechnen muss.