feature: praesi2

praesentation/slides.md

@@ -38,14 +38,14 @@ class: text-center
 <div class="pt-3 font-semibold text-sm">Szenario</div>
 </div>
 
-<div class="flex items-center text-2xl opacity-40">⮀</div>
+<div class="flex items-center text-2xl opacity-40">→</div>
 
 <div class="w-36 p-5 rounded-xl bg-gray-400/10">
 <div class="text-4xl">🗺️</div>
 <div class="pt-3 font-semibold text-sm">ER-Modell</div>
 </div>
 
-<div class="flex items-center text-2xl opacity-40">⮀</div>
+<div class="flex items-center text-2xl opacity-40">→</div>
 
 <div class="w-36 p-5 rounded-xl bg-gray-400/10">
 <div class="text-4xl">🧩</div>
@@ -270,9 +270,10 @@ enemy:1
 </div>
 
 <!--
-- Keys sind Strings und identifizieren ein Objekt eindeutig
-- Aufbau: Name der Entität, Doppelpunkt, ID
-- meiste Entitäten als Hash Map, Listen und Mengen als SET
+- Beim Key-Value-Modell läuft alles über Schlüssel
+- Jeder Key ist ein String und steht für genau ein Objekt
+- Aufbau ist einfach: Name der Entität, Doppelpunkt, ID
+- Objekte speichern wir als Hash Map, Listen und Mengen als SET
 -->
 
 ---
@@ -296,9 +297,9 @@ layout: default
 </div>
 
 <!--
-- jede Entität bekommt einen eigenen Key
-- Ausrüstung des Players über Sub-Keys, z.B. player:1:armor
-- über den Key direkt ans Objekt, ohne Suchen
+- Jede Entität bekommt ihren eigenen Key
+- Die Ausrüstung hängen wir über Sub-Keys dran, z.B. player:1:armor
+- So kommen wir über den Key direkt ans Objekt, ganz ohne Suchen
 -->
 
 ---
@@ -340,9 +341,9 @@ player {
 </div>
 
 <!--
-- alles Zusammengehörige gebündelt in einem Dokument
-- jede Entität eigene Collection
-- Player hält von der Ausrüstung nur die ids fest
+- Beim Dokument-Modell packen wir Zusammengehöriges in ein Dokument
+- Jede Entität bekommt ihre eigene Collection
+- Vom Spieler aus halten wir bei der Ausrüstung nur die ids fest
 -->
 
 ---
@@ -398,9 +399,9 @@ Weapon trägt item_type und item_effect direkt. Sonst meist nur ids.
 </div>
 
 <!--
-- Weapon bringt item_type und item_effect direkt mit
+- Die Weapon bringt item_type und item_effect direkt mit
 - Enemy und Region verweisen über ids auf ihre Items
-- bei uns meist nur ids statt tiefer Verschachtelung
+- Bei uns sind es also meist nur ids statt tiefer Verschachtelung
 -->
 
 ---
@@ -431,8 +432,9 @@ Jede Entität ein Knoten mit eigenen Werten.
 </div>
 
 <!--
-- Fokus liegt auf den Beziehungen zwischen Objekten
-- jede Entität wird ein Knoten und trägt seine Werte direkt
+- Beim Graph-Modell liegt der Fokus auf den Beziehungen
+- Jede Entität wird ein Knoten und trägt ihre Werte direkt
+- Die Verbindungen kommen dann über die Kanten dazu
 -->
 
 ---
@@ -457,9 +459,9 @@ Kanten wie im ER-Modell.
 </div>
 
 <!--
-- Kanten sind die Beziehungen aus dem ER-Modell
-- has_equipped, is_in, has, drops
-- Beziehungen lassen sich direkt verfolgen
+- Die Kanten sind genau die Beziehungen aus dem ER-Modell
+- Zum Beispiel has_equipped, is_in, has und drops
+- Damit lassen sich die Beziehungen direkt verfolgen
 -->
 
 ---
@@ -483,9 +485,9 @@ Komplexe Abfragen müssen wir selbst zusammenbauen.
 </div>
 
 <!--
-- Vorteil: extrem schnell, direkter Zugriff über Key, ideal für Live-Daten
-- Nachteil: komplexe Abfragen müssen wir selbst zusammenbauen
-- Beispiel: alle Weapon mit bestimmtem item_effect
+- Der Vorteil ist das Tempo: über den Key direkt ans Objekt, ideal für Live-Daten
+- Der Nachteil: komplexe Abfragen müssen wir selbst zusammenbauen
+- Zum Beispiel alle Weapon mit einem bestimmten item_effect
 -->
 
 ---
@@ -509,9 +511,9 @@ Bei uns meist nur ids. Stärke kaum genutzt.
 </div>
 
 <!--
-- Vorteil: sehr leserlich und einfach zu modellieren
-- Nachteil: bei uns meist ids, kaum verschachtelt
-- die eigentliche Stärke nutzen wir kaum
+- Der Vorteil: sehr leserlich und einfach zu modellieren
+- Der Nachteil: bei uns sind es meist nur ids, kaum verschachtelt
+- Die eigentliche Stärke nutzen wir damit kaum aus
 -->
 
 ---
@@ -535,37 +537,49 @@ Für uns überdimensioniert. Wir brauchen vor allem Tempo.
 </div>
 
 <!--
-- Vorteil: Beziehungen sehr leicht abfragbar
-- Beispiel: welcher Player welche Weapon trägt, welches Item ein Enemy droppt
-- Nachteil: für unseren Fall überdimensioniert
-- wir brauchen schnelles Schreiben und Lesen, keine tiefen Abfragen
+- Der Vorteil: Beziehungen lassen sich super leicht abfragen
+- Etwa welcher Player welche Weapon trägt oder welches Item ein Enemy droppt
+- Der Nachteil: für unseren Fall ist das überdimensioniert
+- Wir brauchen schnelles Schreiben und Lesen, keine tiefen Abfragen
 -->
 
 ---
 layout: default
 ---
 
-# Gegenüberstellung
+# Was bringt uns welches Modell?
 
-<div class="pt-8 text-lg">
+<div class="grid grid-cols-3 gap-6 pt-12 text-center">
 
-| | Key-Value | Dokument | Graph |
-|---|:---:|:---:|:---:|
-| Schreiben und Lesen | ✅ sehr schnell | 🟡 gut | 🟡 mehr Aufwand |
-| Direkter Objektzugriff | ✅ über Key | ✅ über Collection | 🟡 über Knoten |
-| Komplexe Abfragen | 🔴 schwierig | 🟡 mittel | ✅ stark |
-| Passt zu Live Daten | ✅ ideal | 🟡 ok | 🔴 überdimensioniert |
+<div class="p-6 rounded-xl bg-red-400/10">
+<div class="text-2xl font-bold">Key-Value</div>
+<div class="pt-4 text-3xl">⚡</div>
+<div class="pt-3 text-sm opacity-80">Live-Daten des Players sofort lesen</div>
+</div>
+
+<div class="p-6 rounded-xl bg-green-400/10">
+<div class="text-2xl font-bold">Dokument</div>
+<div class="pt-4 text-3xl">📖</div>
+<div class="pt-3 text-sm opacity-80">Ganzer Player mit Ausrüstung in einem Dokument</div>
+</div>
+
+<div class="p-6 rounded-xl bg-blue-400/10">
+<div class="text-2xl font-bold">Graph</div>
+<div class="pt-4 text-3xl">🔗</div>
+<div class="pt-3 text-sm opacity-80">Welches Item ein Enemy droppt, direkt abfragbar</div>
+</div>
 
 </div>
 
-<div class="pt-8 opacity-70">
-Unsere Daten sind flach und ständig in Bewegung.
+<div class="pt-10 text-center opacity-70">
+Wir brauchen vor allem Tempo.
 </div>
 
 <!--
-- Tabelle fasst die drei Modelle zusammen
-- Key-Value vorn bei Tempo und direktem Zugriff
-- unsere Daten flach und ständig in Bewegung
+- Key-Value gibt uns Tempo pur
+- Dokument ist schön übersichtlich
+- Graph ist stark bei den Beziehungen
+- Für uns zählt am Ende vor allem das Tempo
 -->
 
 ---
@@ -579,9 +593,10 @@ layout: default
 | | Redis | MongoDB | Neo4j |
 |---|:---:|:---:|:---:|
 | Performanz | 2 | 1 | 1 |
-| Streaming | 2 | 0 | 0 |
-| Latenz | 2 | 0 | 1 |
-| **Summe** | **30** | **15** | **13** |
+| Indexing | 1 | 1 | 1 |
+| Latenz | 2 | 0 | 0 |
+| ... weitere Kriterien | ... | ... | ... |
+| **Summe** | **30** | **15** | **14** |
 
 </div>
 
@@ -590,9 +605,9 @@ Redis gewinnt klar.
 </div>
 
 <!--
-- Kriterien aus dem Szenario gewichtet
-- Performanz und keine Lizenzkosten sind Pflicht
-- in den Tests gewinnt Redis klar: 30 vs 15 vs 13
+- Wir haben Kriterien aus dem Szenario aufgestellt und gewichtet
+- Performanz und keine Lizenzkosten sind für uns Pflicht
+- Am Ende gewinnt Redis klar: 30 gegen 15 gegen 14
 -->
 
 ---
@@ -626,9 +641,9 @@ Flache Daten, keine tiefe Verschachtelung.
 </div>
 
 <!--
-- Wahl fällt auf Key-Value mit Redis
-- drei Gründe: Geschwindigkeit, direkter Zugriff, passende Größe
-- komplexe Abfragen brauchen wir kaum
+- Unsere Wahl fällt auf Key-Value mit Redis
+- Drei Gründe: Geschwindigkeit, direkter Zugriff und die passende Größe
+- Komplexe Abfragen brauchen wir bei uns kaum
 -->
 
 ---
@@ -636,12 +651,7 @@ layout: center
 class: text-center
 ---
 
-# Danke
-
-<div class="opacity-80 pt-4 text-lg">
-Nächste Schritte: Datenbank auf dem Server aufsetzen und Schema umsetzen
-</div>
-
+# Danke fürs Zuhören
 <div class="pt-10 opacity-60">
 Fragen?
 </div>
@@ -651,7 +661,7 @@ Justin Rost · Michelle Reichelt · Yasin Ergün
 </div>
 
 <!--
-- Dank fürs Zuhören
-- nächste Schritte: Datenbank auf Server aufsetzen, Schema umsetzen
-- offen für Fragen
+- Danke fürs Zuhören
+- Als nächstes setzen wir die Datenbank auf dem Server auf und bauen das Schema um
+- Jetzt sind wir offen für eure Fragen
 -->