Softwareprojekt

[Sven Rautenberg]

Moin!

Okay, wir müssen halt Java verwenden. Wie oben schon gesagt, es wird keine Webanwendung. Frank hat gemeint wir sollen gar keine Datenbank verwenden.

Sehe ich ähnlich. Datenbank nur für permanente Datenspeicherung. Oder wenn wirklich große Datenmengen zu speichern sind. Aber dann kriegt ihr das Projekt nicht in 7 Wochen durchgezogen, weil große Datenmengen in der Regel nur bei komplexen Spielen anfallen werden.

Aber ich seh das anderst. Nehmen wir folgendes Beispiel. Es haben sich am Server 7, 8 Spieler angemeldet und spielen. Wird nun eine bestimmte Karte an einen Spieler ausgegeben, genügt ein simples Update... (einzeiler) um die Änderung zu registrieren. Auch Abfragen bezüglich des Benutzers könen/müssen in das Update hinein.

Du sagst, du schreibst keine Webanwendung (also etwas, das über HTTP mit einem Browser kommuniziert), aber du denkst die zu erzielende Lösung so.

Mal allgemein gesprochen: Der Java-Client verbindet sich mit dem Spielserver. Da landet er erstmal in einer zentralen "Lobby", in der der Benutzer sich anmeldet (oder zumindest einen Benutzernamen liefert) und aktive Spiele angezeigt kriegt.

Wenn sich mehrere Spieler zum Start eines Kartenspiels (als Beispiel) melden, dann gibts einen abgespaltenen Prozess, der sich um die Abwicklung des Spiels kümmert. Welcher Spieler welche Karte hat, speichert der Server dabei logischerweise am besten im RAM - bei Java also in einer geeigneten Datenstruktur auf dem Heap. Bei schätzungsweise 52 oder vielleicht 104 Spielkarten pro Spiel dürfte sich der Speicheraufwand deutlich im unmerklichen Bereich bewegen. Dafür aber eine Datenbankanbindung zu stricken wird vermutlich viel aufwendiger.

Ich würde auch die permanente Datenspeicherung nicht zwingend in einer Datenbank machen, sondern irgendetwas verwenden, was Java u.U. schon von sich aus mitbringt. Gibts da nicht irgendwas, mit dem man Objekte serialisiert in Dateien schreiben kann (Hibernate, oder wie das heißt)? Dann mußt du dich primär nur um Java kümmern, und nicht noch um die Findung einer geeigneten Datenbankstruktur, sowie der Konvertierung der Daten hin und zurück.

Würde man ein Array verwenden, hätte man nicht nur einen höheren Aufwand O(n) - okay bei der Größe wäre der auch so minimal. Aber da irgendwo anzufangen strings oder ids zu vergleichen, ich weiß nicht. Ich halte das nicht für wirklich sinnvoll. Ich glaube eine Datenbank für den Code außerdem übersichtlier bzw. einfacher gestalten.

Ich glaube an das Gegenteil, abgesehen davon, dass das O des O(n) bei Speicherung im RAM deutlich kleiner ist, als das eventuelle O im O(log n) des indizierten Datenbankzugriffs (was übrigens nur fürs Lesen gilt, beim Schreiben hast du natürlich die üblichen Dinge wie Locking, Index-Updating etc, die ebenfalls Zeit fressen - vom notwendigen Parsing des SQL-Statements und der Kommunikation mit der Datenbank über ein (Unix- oder TCP/IP-)Socket mal ganz abgesehen.

Da reißt die Datenbankmethode vielleicht erst bei extrem hoher paralleler Nutzung was raus - die aber für diese Übungsaufgabe vollkommen irrelevant ist. Du optimierst gedanklich schon eine Lösung, die noch gar nicht existiert, und die auch noch gar kein Performanceproblem hatte. In den 7 Wochen Projektlaufzeit habt ihr für solche Dinge wirklich keine Zeit.

- Sven Rautenberg