Frank (no reg): Softwareprojekt

Beitrag lesen

Hallo zur Nacht nochmals,

die Frage nach den Benutzerdaten war mehr oder weniger eine Fangfrage um zu sehen, ob du weisst warum du was willst. Von Registrierung für die Spiele war im Ausgangsbeitrag ja keine Rede.

Spielstände: es gibt z. B. 52 karten, es muss gespeichert werden, welcher Spieler die Teilmenge 1 hat, welcher Spieler die Teilmenge 2 hat und welche übrig geblieben sind.

Muss es? Stell dir vor, du hast 10.000 gleichzeitige Spieler und jedesmal, wenn eine Karte gegeben/gezogen wurde, musst du ein Update/Insert/Delete auf die Datenbank machen? Hast du dir überlegt, wie lang solch ein Spiel max. laufen soll? Soll man es unterbrechen können müssen? Du bringst mit der Datenbank eine Ressource ins Spiel, die es für eine KI nicht braucht und auch nicht unbedingt für einen Controller/KI. Für Statistiken über die Spiele - keine Einwände, aber für die Abwicklung des Spiels ... tssss??!!

bequem aus der Datenbank mit nur einer einzigen Zeile Select... where user... bestimmt werden

Wow ... mit nur einer einzigen Zeile!?? Dein Prof sollte dir dafür ne Auszeichnung verleihen. Aber ehrlich, mehr als ein Select wäre auch sinnlos.

Würden wir ein Array verwenden, hätten wir da wesentlich mehr aufwand.

"Würden" und "hätten" klingt aber nicht nach "wirklich ausprobiert"! Habt ihr überhaupt schon mal was ausprobiert?

Also was bietet euch eine Datenbank _wirklich_ für Vorteile dabei?

Synchrone Methodenaufrufe sind nicht gerade ideal für solche Szenarien, da der ausführende Thread, ob Client oder Server jeweils auf die Rückkehr des Messiahs äh des Aufrufs wartet. Damit könnt ihr keinen Multiuser-Betrieb sinnvoll (wenn überhaupt) gewährleisten. Deswegen erwähnte ich auch Eventing. Dazwischen kehren alle Teilnehmer immer in einen bekannten (==definierten) Ruhezustand/Idle State zurück.

Ansonsten stimme ich restlos dem Sven zu. :)

Ciao und gutnacht
Frank