Glück auf! Ich speichere Spielstatistikdaten aus einer API in einer MySQL-Tabelle. Diese ist aktuell wie folgt aufgebaut. Spalten: - id = Primärkey - wbbid = Key des Spielers in Benutzerliste des Forums - idSpielerSpiel = Redundanter Key aus Spielername und Spiel (hat mir die Ausgabe erleichtert) - spielername = Spielername - spiel = Name des Spiels (aktuell werden Daten aus 4 Spielen eingelesen) - plattform = ps3/ps4 (für Playstation 3 oder 4) - ... = einige grundlegenden Statistikwerte (wie spielzeit, siege usw.) - j_rangfolge = Hier speichere ich ca. 500 Statistikwerte im json-Format (darum dreht es sich gleich) - statsUpdate = Datum des letzten Updates der API - tabUpdate = Datum des letzten Updates dieser Tabelle - fehlgUpdates = Anzahl der aufeinanderfolgend fehlgeschlagenen Updates Bei aktuell 4 Spielen und ca. 50 Spielern je Spiel habe ich so ca. 200 Datensätze. Nun würde ich gerne in die Tabelle auch historische Werte aufnehmen. Bei einem täglichen Update würden die Datensätze somit um den Faktor 365 steigen = 73.600 Datensätze. Langfristig kommen auch noch neue Spiele hinzu und die Spielerzahl steigt auch langsam. Im Zuge der Überarbeitung der Datenbankstruktur würde ich darüberhinaus gerne die Spalte mit den json-Werten abschaffen. Ich hatte mir das so vorgestellt, dass ich die obige Tabelle um die Statistikwerte (...) und die json-Spalte (j_rangfolge) bereinige und dafür eine neue Tabelle erstelle, die wie folgt aufgebaut ist: - id = Primärkey - sid = ID aus der Tabelle oben - bez = Bezeichnung des aktuellen Wertes (z.B. spielzeit, siege usw.) - kat = Kategorie des Wertes (z.B. Spieler, Fahrzeuge, Aufträge usw.) - art = Art des Wertes z.B. prozent, boolean, kills ... - wert = Wert (= der eigentliche Wert) Ich weiß noch nicht, wie ich mit der Programmierung der Ausgabe am Ende klar komme, aber ich glaube das dürfte ich hinkriegen. Was mir jedoch Sorgen bereitet ist die Anzahl der Datensätze. Denn je Datensatz aus der obigen Tabelle (73.000 DS) hätte ich jetzt noch ca. 500 Einzelwerte aus der neuen Tabelle => 36.500.000 (Datensätze!!!). Wegen den 36.500.000 Datensätzen hab ich mich erstmal total erschrocken und bin dann zu der Erkenntnis gekommen, dass ich ja auch nur die letzten 10 Updates je Spieler abspeichern könnte. Das macht dann (wenn ich mich jetzt nicht selbst verwirrt habe): 4 Spiele x 50 Spieler x 10 Datenstände x 500 Einzelwerte = 1.000.000 Datensätze Fragen: 1) Sind 1.000.000 Datensätze (langfristig vlt. 2 - 3 Mio.) ein Wert mit dem man grds. (normalerweise) performant arbeiten kann? 2) Sollte ich die aktuellen und historischen Werte in zwei unterschiedlichen Tabellen speichern, um die häufige Abfrage der aktuellen Werte zu beschleunigen? Die Abfrage der historischen Werte bzw. der Entwicklung wird vmtl. weniger abgefragt und für die Standardausgabe nicht benötigt. 3) Wäre eine Tabelle je Spiel sinnvoll (bzw. bei obigen Aufbau zwei Tabellen je Spiel), wenn zwar der Aufbau der gleiche ist, aber die Daten eigentlich nie zusammenhängend abgefragt/benötigt werden? 4) Ist der angedachte Tabellenaufbau ansonsten ok oder stich euch direkt etwas ins Auge? Wie immer gilt, dass ich versucht habe, nach besten Wissen und Gewissen, wesentliche Dinge zu erwähnen und unwesentliche Dinge rauszukürzen. Sollten mehr Informationen benötigt werden, reiche ich die gerne nach. Freundliche Grüße Kackfohgel

Glück auf! Ich speichere Spielstatistikdaten aus einer API in einer MySQL-Tabelle. Diese ist aktuell wie folgt aufgebaut. Spalten: - id = Primärkey - wbbid = Key des Spielers in Benutzerliste des Forums - idSpielerSpiel = Redundanter Key aus Spielername und Spiel (hat mir die Ausgabe erleichtert) - spielername = Spielername - spiel = Name des Spiels (aktuell werden Daten aus 4 Spielen eingelesen) - plattform = ps3/ps4 (für Playstation 3 oder 4) - ... = einige grundlegenden Statistikwerte (wie spielzeit, siege usw.) - j_rangfolge = Hier speichere ich ca. 500 Statistikwerte im json-Format (darum dreht es sich gleich) - statsUpdate = Datum des letzten Updates der API - tabUpdate = Datum des letzten Updates dieser Tabelle - fehlgUpdates = Anzahl der aufeinanderfolgend fehlgeschlagenen Updates Bei aktuell 4 Spielen und ca. 50 Spielern je Spiel habe ich so ca. 200 Datensätze. Nun würde ich gerne in die Tabelle auch historische Werte aufnehmen. Bei einem täglichen Update würden die Datensätze somit um den Faktor 365 steigen = 73.600 Datensätze. Langfristig kommen auch noch neue Spiele hinzu und die Spielerzahl steigt auch langsam. Im Zuge der Überarbeitung der Datenbankstruktur würde ich darüberhinaus gerne die Spalte mit den json-Werten abschaffen. Ich hatte mir das so vorgestellt, dass ich die obige Tabelle um die Statistikwerte (...) und die json-Spalte (j_rangfolge) bereinige und dafür eine neue Tabelle erstelle, die wie folgt aufgebaut ist: id = Primärkey sid = ID aus der Tabelle oben bez = Bezeichnung des aktuellen Wertes (z.B. spielzeit, siege usw.) kat = Kategorie des Wertes (z.B. Spieler, Fahrzeuge, Aufträge usw.) art = Art des Wertes z.B. prozent, boolean, kills ... wert = Wert (= der eigentliche Wert) Ich weiß noch nicht, wie ich mit der Programmierung der Ausgabe am Ende klar komme, aber ich glaube das dürfte ich hinkriegen. Was mir jedoch Sorgen bereitet ist die Anzahl der Datensätze. Denn je Datensatz aus der obigen Tabelle (73.000 DS) hätte ich jetzt noch ca. 500 Einzelwerte aus der neuen Tabelle => 36.500.000 (Datensätze!!!). Wegen den 36.500.000 Datensätzen hab ich mich erstmal total erschrocken und bin dann zu der Erkenntnis gekommen, dass ich ja auch nur die letzten 10 Updates je Spieler abspeichern könnte. Das macht dann (wenn ich mich jetzt nicht selbst verwirrt habe): 4 Spiele x 50 Spieler x 10 Datenstände x 500 Einzelwerte = 1.000.000 Datensätze Fragen: 1) Sind 1.000.000 Datensätze (langfristig vlt. 2 - 3 Mio.) ein Wert mit dem man grds. (normalerweise) performant arbeiten kann? 2) Sollte ich die aktuellen und historischen Werte in zwei unterschiedlichen Tabellen speichern, um die häufige Abfrage der aktuellen Werte zu beschleunigen? Die Abfrage der historischen Werte bzw. der Entwicklung wird vmtl. weniger abgefragt und für die Standardausgabe nicht benötigt. 3) Wäre eine Tabelle je Spiel sinnvoll (bzw. bei obigen Aufbau zwei Tabellen je Spiel), wenn zwar der Aufbau der gleiche ist, aber die Daten eigentlich nie zusammenhängend abgefragt/benötigt werden? 4) Ist der angedachte Tabellenaufbau ansonsten ok oder stich euch direkt etwas ins Auge? Wie immer gilt, dass ich versucht habe, nach besten Wissen und Gewissen, wesentliche Dinge zu erwähnen und unwesentliche Dinge rauszukürzen. Sollten mehr Informationen benötigt werden, reiche ich die gerne nach. Freundliche Grüße Kackfohgel