diff --git a/praesentation/slides.md b/praesentation/slides.md
index 65d895b9..785050ca 100644
--- a/praesentation/slides.md
+++ b/praesentation/slides.md
@@ -248,11 +248,13 @@ layoutClass: gap-10
 
 # Key-Value mit Redis
 
-Eine einfache und schnelle Lösung für unstrukturierte Daten.
+<div class="pt-8 text-lg space-y-4 opacity-80">
 
-Keys sind Strings und identifizieren ein Objekt eindeutig.
+Keys sind Strings, eindeutig pro Objekt.
 
-Aufbau: Name der Entität, Doppelpunkt, ID des Objekts.
+Aufbau: Entität : ID
+
+</div>
 
 ::right::
 
@@ -267,12 +269,6 @@ enemy:1
 
 </div>
 
-<div class="pt-6 opacity-80">
-
-Die meisten Entitäten liegen als Hash Map. Listen und Mengen als SET.
-
-</div>
-
 <!--
 - Keys sind Strings und identifizieren ein Objekt eindeutig
 - Aufbau: Name der Entität, Doppelpunkt, ID
@@ -289,19 +285,14 @@ layout: default
 
 | Datentyp | Key-Struktur | Attribute |
 |----------|--------------|-----------|
-| HMAP | `weapon:{id}` | id, item_effect_id, item_type_id, weight, damage |
-| HMAP | `item:{id}` | id, name, gear_type, gear_id |
-| HMAP | `player:{id}` | id, name, health, stamina, level, region_id |
+| HMAP | `player:{id}` | id, name, health, level, region_id |
 | SET | `player:{id}:armor` | item_id |
-| STRING | `player:{id}:shield` | item_id |
-| HMAP | `region:{id}` | id, name |
-| SET | `region:{id}:enemies` | enemy_id |
-| HMAP | `enemy:{id}` | id, name, health, level, damage |
+| HMAP | `enemy:{id}` | id, name, health, damage |
 
 </div>
 
 <div class="pt-4 opacity-70 text-sm">
-Über den Key kommen wir direkt an ein Objekt, ohne lange zu suchen.
+Über den Key direkt ans Objekt.
 </div>
 
 <!--
@@ -317,11 +308,15 @@ layoutClass: gap-10
 
 # Dokument mit MongoDB
 
-Alles was zusammengehört, liegt gebündelt in einem Dokument.
+<div class="pt-8 text-lg space-y-4 opacity-80">
 
-Jede Entität wird zu einem Dokument in einer eigenen Collection.
+Zusammengehöriges in einem Dokument.
 
-Der Player hält von seiner Ausrüstung nur die ids fest, denn Weapon und Co. liegen in eigenen Dokumenten.
+Jede Entität eine Collection.
+
+Ausrüstung nur als ids.
+
+</div>
 
 ::right::
 
@@ -399,7 +394,7 @@ region {
 </div>
 
 <div class="pt-6 opacity-70 text-sm">
-Weapon bringt item_type und item_effect direkt mit. Player, Item, Region und Enemy zeigen meist nur über ids.
+Weapon trägt item_type und item_effect direkt. Sonst meist nur ids.
 </div>
 
 <!--
@@ -415,9 +410,13 @@ layoutClass: gap-10
 
 # Graph mit Neo4j
 
-Der Fokus liegt auf den Beziehungen zwischen den Objekten.
+<div class="pt-8 text-lg space-y-4 opacity-80">
 
-Jede Entität wird zu einem Knoten, der seine Werte direkt mitträgt.
+Fokus auf den Beziehungen.
+
+Jede Entität ein Knoten mit eigenen Werten.
+
+</div>
 
 ::right::
 
@@ -425,13 +424,9 @@ Jede Entität wird zu einem Knoten, der seine Werte direkt mitträgt.
 
 | Knoten | Attribute |
 |--------|-----------|
-| Player | id, name, health, stamina, level |
+| Player | id, name, health, level |
 | Weapon | id, weight, damage |
-| Type | id, name |
-| item_effect | id, name, value |
-| Item | id, name |
-| Region | id, name |
-| Enemy | id, name, health, level, damage |
+| Enemy | id, name, health, damage |
 
 </div>
 
@@ -450,18 +445,15 @@ layout: default
 
 | Von | Kante | Nach |
 |-----|-------|------|
-| Player | has_equipped | Weapon, Armor, Shield, Talisman |
+| Player | has_equipped | Weapon |
 | Player | is_in | Region |
-| Weapon, Armor, Shield | has | Type |
-| Weapon, Armor, Shield, Talisman | has | item_effect |
-| Weapon, Armor, Shield, Talisman | is | Item |
-| Region | has | Item, Enemy |
+| Region | has | Enemy |
 | Enemy | drops | Item |
 
 </div>
 
 <div class="pt-6 opacity-70 text-sm">
-Die Kanten verbinden die Knoten so, wie es schon das ER-Modell vorgibt.
+Kanten wie im ER-Modell.
 </div>
 
 <!--
@@ -480,12 +472,12 @@ layout: default
 
 <div class="p-6 rounded-xl bg-green-500/10">
 <div class="font-bold text-green-500 pb-3">Vorteil</div>
-Redis ist extrem schnell. Über die Keys kommen wir direkt an ein Objekt. Genau das brauchen wir für die Live Daten des Players.
+Extrem schnell, direkter Zugriff über Key. Ideal für Live Daten.
 </div>
 
 <div class="p-6 rounded-xl bg-red-500/10">
 <div class="font-bold text-red-500 pb-3">Nachteil</div>
-Komplexe Abfragen sind schwierig. Alle Weapon mit einem bestimmten item_effect müssen wir in der Anwendung selbst zusammenbauen.
+Komplexe Abfragen müssen wir selbst zusammenbauen.
 </div>
 
 </div>
@@ -506,12 +498,12 @@ layout: default
 
 <div class="p-6 rounded-xl bg-green-500/10">
 <div class="font-bold text-green-500 pb-3">Vorteil</div>
-Sehr leserlich und einfach zu modellieren. Jedes Dokument ist für sich verständlich und man sieht direkt, welche Daten zusammengehören.
+Leserlich und einfach zu modellieren.
 </div>
 
 <div class="p-6 rounded-xl bg-red-500/10">
 <div class="font-bold text-red-500 pb-3">Nachteil</div>
-Bei uns wird das meiste über ids referenziert und nur wenig verschachtelt. Wir nutzen die Stärke des Modells kaum.
+Bei uns meist nur ids. Stärke kaum genutzt.
 </div>
 
 </div>
@@ -532,12 +524,12 @@ layout: default
 
 <div class="p-6 rounded-xl bg-green-500/10">
 <div class="font-bold text-green-500 pb-3">Vorteil</div>
-Beziehungen lassen sich sehr leicht abfragen. Welcher Player welche Weapon trägt oder welches Item ein Enemy fallen lässt, ohne Umwege.
+Beziehungen sehr leicht abfragbar, ohne Umwege.
 </div>
 
 <div class="p-6 rounded-xl bg-red-500/10">
 <div class="font-bold text-red-500 pb-3">Nachteil</div>
-Neo4j ist für unseren Fall überdimensioniert. Wir schreiben und lesen vor allem schnell, statt ständig tiefe Beziehungen abzufragen.
+Für uns überdimensioniert. Wir brauchen vor allem Tempo.
 </div>
 
 </div>
@@ -567,7 +559,7 @@ layout: default
 </div>
 
 <div class="pt-8 opacity-70">
-Unsere Daten sind flach und ändern sich ständig. Tiefe Beziehungen brauchen wir kaum.
+Unsere Daten sind flach und ständig in Bewegung.
 </div>
 
 <!--
@@ -582,41 +574,25 @@ layout: default
 
 # Was uns wichtig ist
 
-<div class="grid grid-cols-2 gap-8 pt-6 text-sm">
+<div class="pt-10 text-lg">
 
-<div>
-
-| Kriterium | Muss | Gewicht |
-|-----------|:----:|:-------:|
-| Hohe Performanz | ja | 5 |
-| Keine Lizenzkosten | ja | 5 |
-| Daten-Streaming | ja | 3 |
-| Niedrige Latenz | ja | 3 |
-| Indexing | nein | 2 |
-
-</div>
-
-<div>
-
-| | MariaDB | Redis | MongoDB |
+| | Redis | MongoDB | Neo4j |
 |---|:---:|:---:|:---:|
-| Performanz | 0 | 2 | 1 |
-| Streaming | 0 | 2 | 0 |
-| Latenz | 1 | 2 | 0 |
-| **Summe** | **11** | **30** | **15** |
-
-</div>
+| Performanz | 2 | 1 | 1 |
+| Streaming | 2 | 0 | 0 |
+| Latenz | 2 | 0 | 1 |
+| **Summe** | **30** | **15** | **13** |
 
 </div>
 
 <div class="pt-6 opacity-70 text-sm">
-Latenzfrei und performant ist für uns Pflicht. In den Tests gewinnt Redis klar.
+Redis gewinnt klar.
 </div>
 
 <!--
 - Kriterien aus dem Szenario gewichtet
 - Performanz und keine Lizenzkosten sind Pflicht
-- in den Tests gewinnt Redis klar: 30 vs 11 vs 15
+- in den Tests gewinnt Redis klar: 30 vs 15 vs 13
 -->
 
 ---
@@ -634,17 +610,17 @@ Wir wählen <span class="text-red-500 font-bold">Key-Value mit Redis</span>
 
 <div class="p-5 rounded-xl bg-gray-400/10">
 <div class="font-semibold pb-2">Geschwindigkeit</div>
-Daten des Players live schreiben und genauso live zurücklesen.
+Live schreiben und lesen.
 </div>
 
 <div class="p-5 rounded-xl bg-gray-400/10">
 <div class="font-semibold pb-2">Direkter Zugriff</div>
-Über die Keys sofort an ein Objekt, ohne lange Suche.
+Über den Key sofort ans Objekt.
 </div>
 
 <div class="p-5 rounded-xl bg-gray-400/10">
 <div class="font-semibold pb-2">Passende Größe</div>
-Rund 100 Regionen, 500 Gegner, 3.300 Gegenstände. Keine tiefe Verschachtelung nötig.
+Flache Daten, keine tiefe Verschachtelung.
 </div>
 
 </div>