feature: fertig

Ringstats_Dokumentation.tex

@@ -222,6 +222,7 @@ weapon {
 }
 \end{verbatim}
 
+\newpage
 Und so ein Enemy, der seine Item als id behält:
 
 \begin{verbatim}
@@ -260,8 +261,6 @@ region {
 \newpage
 
 \subsection{Graph-Datenbank-Modellierung}
-\todo{komplett pruefen ob wir das richtig verstanden haben}
-% Wie sieht das in z. B. Neo4j aus? Beschreibt (oder zeichnet), wie Knoten (Player, Region) und Kanten (has_equipped, is_in) die Beziehungen darstellen.
 Graph-Datenbanken legen den Fokus auf die Beziehungen zwischen den Objekten.
 Wir verwenden in diesem Kapitel Neo4j.
 
@@ -324,12 +323,12 @@ Ein klarer Vorteil ist, dass das Modell extrem leserlich und einfach zu modellie
 Ein klarer Nachteil ist bei uns, dass das meiste über ids referenziert wird und nur wenig wirklich verschachtelt ist. Zwar bringt eine Weapon ihren item\_type und item\_effect direkt mit, aber Player, Item, Region und Enemy zeigen größtenteils nur über ids aufeinander. Dadurch nutzen wir die eigentliche Stärke des Modells kaum und haben am Ende vor allem viele einzelne Dokumente, die sich gegenseitig referenzieren.
 
 \subsection{Vor- und Nachteile des Graph-Modells}
-% Vorteil: Genial, um Beziehungen abzufragen (z.B. Welcher Spieler trägt welches Item, das von welchem Boss droppt?). Nachteil: Für pures Live-Streaming von Koordinaten eher überdimensioniert.
-% Siehe Dokumenatation der Datenmodellierung
+\todo[inline]{Wir koennten Regionen Traversierung Pathfinding einbauen}
 Ein klarer Vorteil ist, dass sich Beziehungen sehr leicht abfragen lassen.
 Wir können zum Beispiel direkt verfolgen, welcher Player welche Weapon trägt oder welches Item ein Enemy fallen lässt,
 ohne die Verbindungen umständlich selbst zusammenzubauen.
 
+\todo[inline]{Wir haben keine Beziehungen, die ueber mehrere Knoten hinweg gehen. Keine komlexen beziehungen wo der graph einen hohen nutzen mit sich bringt}
 Ein klarer Nachteil ist, dass Neo4j für unseren Fall überdimensioniert ist.
 Bei uns geht es vor allem darum, die Daten des Player schnell zu schreiben und wieder auszulesen, und nicht darum, ständig tiefe Beziehungen abzufragen.
 Für dieses einfache Schreiben und Lesen bringt der Graph mehr Aufwand mit, als er uns am Ende Vorteil bringt.
@@ -342,8 +341,26 @@ Für dieses einfache Schreiben und Lesen bringt der Graph mehr Aufwand mit, als
 % Mehr coole sachen die wir gelernt haben.
 % Warum wir uns fuer dieses Datenbankmodell entschieden haben.
 Wir haben die gleichen Daten aus unserem ER-Modell in drei Datenbanken abgebildet und dabei gesehen,
-wie verschieden das aussieht. In Redis haben wir alles über Keys und Hash Maps abgelegt und kommen so direkt an ein einzelnes Objekt. In MongoDB liegt jede Entität als Dokument in ihrer Collection, und die Weapon bringt ihren item\_type und item\_effect gleich mit. In Neo4j ist jede Entität ein Knoten und die Verbindungen aus dem ER-Modell werden zu Kanten, also zum Beispiel has\_equipped oder drops. So konnten wir gut vergleichen, was jedes Modell bei unseren Daten gut kann und was eher umständlich ist.
+wie verschieden das aussieht. In Redis haben wir alles über Keys und Hash Maps abgelegt und kommen so direkt an ein einzelne Objekte.
+In MongoDB liegt jede Entität als Dokument in ihrer Collection, und die Weapon bringt ihren item\_type und item\_effect gleich mit.
+In Neo4j ist jede Entität ein Knoten und die Verbindungen aus dem ER-Modell werden zu Kanten,
+also zum Beispiel has\_equipped oder drops.
+
+Aufgefallen ist uns, dass wir bei Redis und MongoDB mehrere Anfragen brauchen,
+weil vieles nur über ids aufeinander zeigt. Bei Redis ist das allerdings kein Problem,
+da diese extrem schnell im Vergleich zu den anderen beiden sind.
+Wollen wir zum Beispiel zu einem Player seine Weapon,
+holen wir erst den Player, dann das Item und dann die Weapon. So konnten wir gut vergleichen,
+was jedes Modell bei unseren Daten gut kann und was eher umständlich ist.
+
+% \todo[inline]{Noch etwas zu Graph, da wir keine Beziehungsketten haben.}
 
 Für Ringstats fällt unsere Wahl auf das Key-Value-Modell mit Redis.
-Der Grund ist einfach: Bei uns geht es vor allem darum, die Daten des Player laufend zu schreiben und sofort wieder auszulesen, im Spiel und im Browser. Genau dafür ist Redis gemacht. Über die Keys kommen wir direkt an ein Objekt und müssen nicht lange suchen. Die komplexen Abfragen, bei denen MongoDB oder Neo4j stark wären, brauchen wir kaum, und unsere Daten sind ohnehin nicht tief verschachtelt. Deshalb passt die schnelle und einfache Lösung am besten zu dem, was Ringstats im Kern macht.
+Der Grund ist einfach: Bei uns geht es vor allem darum,
+die Daten des Player laufend im Spiel und Browser zu schreiben und sofort wieder auszulesen.
+Genau dafür ist Redis gemacht.
+Über die Keys kommen wir direkt an ein Objekt und müssen nicht lange suchen.
+Die komplexen Abfragen, bei denen MongoDB oder Neo4j stark wären, brauchen wir kaum,
+und unsere Daten sind ohnehin nicht tief verschachtelt.
+Deshalb passt die schnelle und einfache Lösung am besten zu dem, was Ringstats braucht.
 \end{document}