Übersichtliche Zuweisung von Daten in Tabellen

[Darokh]

Hi,
ich hoffe, ich bin hier im richtigen Forum gelandet...

Ich möchte Daten, die ich in einem Spiel erhalte, in einer Datenbank speichern, um sie später auswerten zu können.

Es gibt Spiele und so genannte "Subspiele". Ein Beispiel:

Spiel A soll die Reaktionsfähigkeit von Patienten verbessern. Dazu wird zunächst ein SubSpiel a gestartet. Nach einer gewissen Zeit wird aber ein weiteres Subspiel b parallel dazu geschaltet, um den Schwierigkeitsgrad zu erhöhen. Der Patient absolviert also mehrere Aufgaben parallel.

Spiel B könnte nun seinerseits auch aus SubSpiel a bestehen, aber noch SubSpiel c, d und e beinhalten.

Ein Spiel könnte auch als eine Zusammenstellung von SubSpielen verstanden werden, die "nach belieben" zusammengewürfelt werden können.

Also hätten wir schoneinmal soetwas:
Spiel A

SubSpiel a​

SubSpiel b​

Spiel B

SubSpiel a​

SubSpiel c​

SubSpiel d​

SubSpiel e​

Jedes SubSpiel hat ein selbstständig laufendes Level / Schwierigkeitsgrad, welches sich mit der Zeit ebenfalls verändert.
Pro Level in einem SubSpiel sollen Durchschnittswerte gespeichert werden, wie beispielsweise Reaktionszeit, Geschwindigkeit, Anzahl korrekter Antworten. Das ist wiederum pro SubSpiel unterschiedlich.

Ab diesem Punkt fängt mein Kopf an zu schmerzen, wie ich diese Daten in MYSQL am besten tabellarisch auffange.

Nochmals zusammengefasst

- eine Session, zu einem bestimmten Zeitpunkt, Dauer
- einen Patienten / Spieler
- Spiele, welche aus verschiedenen SubSpielen bestehen

Konkrektes Beispiel:
- Spiel A, bestehend aus SubSpiel a + b
- Spiel B, bestehnd aus SubSpiel a, c, d, e
- SubSpiel a erfasst PRO LEVEL (Level 1-10): Reaktionszeit
- SubSpiel b erfasst PRO LEVEL (Level 1-6): Anzahl korrekter Antworten, Anzahl falscher Antworten
- SubSpiel c, d, e erfassen PRO LEVEL ( Level 1-9): Reaktionszeit, Geschwindigkeit


Als erstes wollte ich für jedes SubSpiel eine eigene Tabelle anlegen. Dann pro Spiel wiederum auch eine Tabelle, und dort die SubSpieldaten wieder zusammenfügen. Dann wiederum pro Session zusammenführen.
Mir erscheint das zwar übersichtlich in Sachen Tabellenkonstruktion, aber glaube, dass es dann sehr viele unnötige Verweise gibt.
Das ganze sollte eben möglichst gut damit klarkommen, wenn ich noch mehrere Spiele / SubSpiele hinzufüge.
Bei den ganzen Querverweisen habe ich dann aber irgendwie Angst, dass ich da nicht ordentlich mit umgehen kann.

Viele Grüße,
darokh

 

[nillehammer]

Nach dem Überfliegen Deiner Beschreibung sieht es für mich so aus, dass alle Spiele (egal ob Root-Spiel oder Sub-Sub-Subspiele) jeweils die gleichen Daten abspeichern. Das heißt für mich, es gibt genau eine Tabelle. Die Referenz auf das Parent machst du mit einer Fremdschlüsselspalte "parent", die auf den Primary key der selben Tabelle referenziert.

Der SQL-Code könnte ungefähr so aussehen (aus dem Gedächtnis getippt, also nich ungeding 100% korrekt):

CREATE TABLE Spiel
(
   id INTEGER UNSIGNED NOT NULL PRIMARY KEY,
   parent_id INTEGER UNSIGNED,
   description VARCHAR(40),
   FOREIGN KEY(parent_id) REFERENCES Spiel(id)
      ON DELETE CASCADE ON UPDATE CASCADE
);

 

[bERt0r]

@nillehammer: Das kann so nicht funktionieren, weil du eine m:n Beziehung zwischen Spielen und Subspielen hast: Ein spiel kann mehrere subspiele haben, ein subspiel kann in mehrerern parent spielen sein.

Im allgemeinen sollte man für sowas ein ER-Diagramm machen, besonders dann wenns zu kompliziert wird.
Nachtrag:
Eine m:n Beziehung löst man über eine seperate Tabelle (z.B Spiel_Hierarchie) auf, die dann aus 2 Fremdschlüssel von Spiel besteht und quasi die sub-super Mappings beinhält.
In wie weit es sinnvoll ist, die Ergebnisse wie Reaktionszeit, etc. auch noch extra als Tabell/Attribut zu erfassen hängt dann vom Anwendungsfall ab.

 

[JanHH]

Hm das ist doch eigentlich simpel. Ich würde daraus eine java-Klassenhierarchie bauen, daraus ergibt sich per JPA dann ja automatisch das Datenbankschema.

Eine Klasse Spiel und eine Klasse SubSpiel und eine Klasse Level.

in Spiel gibt es eine Liste

@OneToMany
private List<SubSpiel> subSpiele;

und in SubSpiel wiederum

@OneToMany
private List<Level> levels;

und ein int, welches den Typ des SubSpiels angibt (1=a, 2=b usw).

und in der Klasse levels gibts halt die member-Variablen/Properties Reaktionszeit usw, die Du da aufführst.

Wenn Du willst kann ich da gerne auch noch mal etwas mehr Code zu schreiben.

 

[Darokh]

Frohes neues Jahr erstmal!

Puh, das ist ja ne ganz schöne Menge nachzulesen Zusätzlich zu meinem derzeitigen Java-Pensum.
Hm, über etwas mehr Code wäre ich sehr dankbar, dann check ist das sicherlich etwas schneller...

 

[nillehammer]

@nillehammer: Das kann so nicht funktionieren, weil du eine m:n Beziehung zwischen Spielen und Subspielen hast: Ein spiel kann mehrere subspiele haben, ein subspiel kann in mehrerern parent spielen sein.

@bERt0r: Ich glaube, hier irrst Du. Wenn ich mich nicht völlig verlesen habe, hat jedes (Sub-)Spiel entweder keinen Parent oder genau einen Parent und damit ist es eine klassische Parent-Child-Beziehung, also 1:n.

 

[bERt0r]

Also ich habs so aufgefasst:
Spiel 1 besteht aus Subspiel A und B
Spiel 2 besteht aus Subspiel A, C ,D und E

 

[nillehammer]

Also ich habs so aufgefasst:
Spiel 1 besteht aus Subspiel A und B
Spiel 2 besteht aus Subspiel A, C ,D und E

Stimmt, steht da so... Dann also m:n mit Beziehungstabelle...

 

[Darokh]

Jup, genau, n:m Beziehung.

Und jedes SubSpiel erhebt unterschiedliche Daten. Pro Level werden diese Daten dann gemittelt oder als Summe gespeichert --> also pro Lvl ein Wert pro Variable (also bspw. Reaktionszeit, Geschwindigkeit).

 

[bERt0r]

Wenn dieser wert immer Numerisch ist isses ja ganz einfach:
Tabelle Ergebnis, Fremdschlüssel für Spiel und Level, fertig.

 

[Darokh]

Also meinst du soetwas wie:
Ergebnisse SubSpiel 1:

ErgebnisIDSubSpiel_1---Level---Reaktionszeit---Geschwindigkeit---korrekte Antworten


Ergebnisse SubSpiel 2:

ErgebnisIDSubSpiel_2---Level---Korrekte Antworten---nocheinenWertDenIchErhebe


Spiel 1 besteht aus SubSpiel 1+2:

Spiel_1_ID---Fremschlüssel:ErgebnisIDSubSpiel_1---Fremschlüssel:ErgebnisIDSubSpiel_1


MasterTabelle
SessionID---User---FremdSchlüssel:Spiel_x_ID

Haut das hin?

 

[bERt0r]

Ich hab ein bisschen in einem Programm gespielt :

Anhang anzeigen 3905

3 m:n Beziehungen:
Zwischen Spiel und Spiel (Drückt eine Hierarchie aus mit Sub und Super-Spielen)
Zwischen Spiel und Ergebnistyp (Jedes Spiel hat eine Auswahl an Messgrößen, die es ermittelt)
Zwischen Ergebnis und Ergebnistyp (Hier stehen die erzielten Werte eines Spiels dann drinn)

Ich glaube das sollte so hinhaun.

 

[JanHH]

Was habt ihr denn da mit n:m immer? Das stimmt doch gar nicht.

Klar können mehrere Spiele SubSpiel A haben, aber das ist doch nicht das gleiche Exemplar von SubSpiel A, sondern ein anderes SubSpiel, aber halt ebenfalls vom Typ A. Das ist eine 1:n Beziehung, ganz eindeutig.

Ein Spiel hat eine 1:n-Beziehung zu den SubSpielen, wobei natürlich mehrere SubSpiele vom Typ "SubSpiel A" existieren können! Jedem Spieler sein eigenes, logischerweise.

Ein SubSpiel wiederum hat eine 1:n-Beziehung zu den Levels, aus denen es besteht.

 

[Darokh]

Da hat JanHH recht...

 

[bERt0r]

Du willst das ganze also in einem ODBMS speichern? Nun das ist dann wieder eine andere Geschichte. Ich weis nicht wie du dir das in einer relationalen DB vorstellst. Wie unterscheidest du die verschiedenen SubSpiel A Objekte in der Datenbank? Wie findest du das richtige für dein Spiel und Ergebnis? Wenn z.B der Highscore in Spiel A Subspiel A von Spiel B Subspiel A überboten wird, merkst du das nicht.

 

[Darokh]

Hm, vielleicht habe ich das noch schwer verständlich ausgedrückt oder etwas missverstanden.

Spiel 1 besteht aus SubSpiel 1, 2 und 3
Spiel 2 besteht aus SubSpiel 2, 3 und 4

Spiel 1 und 2 stehen für sich komplett isoliert - auch deren SubSpiele sind nicht untereinander vergleichbar.
Also
Spiel 1 - SubSpiel 2
Spiel 2 - SubSpiel 2

sind zwar praktisch gesehen genau die gleichen Spiele, aber können trotzdem nicht miteinander verglichen werden, da die Spiele unterschiedliche SubSpiele (oder sogar Aufgabenstellungen, bei gleichen Spielen) haben und somit der Schwierigkeitsgrad auch ein anderer ist.

Also in Spiel 1 ist SubSpiel 2 einfacher, weil die anderen SubSpiele einfacher sind.

Hilft das weiter?

 

[narotiuncdwhear]

Du willst also sowas ähnliches wie das hier programmieren?
Multitask | Puzzle & Skill Games | Play Free Games Online at Armor Games

Bist du dir wirklich sicher, dass die einzelnen Spiele dann auch nochmal unterteilt werden sollen? Irgendwann wirds nämlich einfach übertrieben schwer

 

[JanHH]

Hier mal der rudimentäre Java-Code für JPA-Entity-Klassen / Datenmodell. Getter/Setter wg. Übersichtlichkeit weggelassen.

@Entity
class Level
{
	@Id
	@Column
	@GeneratedValue(strategy=GenerationType.AUTO)
	private long id;

	private int reaktionszeit, anzRichtig, anzFalsch, geschwind;
}

@Entity
public class SubSpiel
{
	public static final int SUBSPIEL_TYP_A=1;
	public static final int SUBSPIEL_TYP_B=2;
	public static final int SUBSPIEL_TYP_C=3;
	public static final int SUBSPIEL_TYP_D=4;
	public static final int SUBSPIEL_TYP_E=5;

	@Id
	@Column
	@GeneratedValue(strategy=GenerationType.AUTO)
	private long id;

	private int type;

	@OneToMany
	private List<Level> levels;
}

@Entity
public class Spiel
{
	@Id
	@Column
	@GeneratedValue(strategy=GenerationType.AUTO)
	private long id;

	@OneToMany
	private List<SubSpiel> subSpiele;
}