Ist dies eine akzeptable Situation, um ein Array in einer Datenbank zu speichern?

Question

Ich habe eine Anwendung entwickelt und bin auf eine Situation gestoßen, in der ich gerne einen Schnappschuss der aktuellen Daten machen würde.

Zum Beispiel werden in dieser Anwendung Benutzer unterschiedliche Statistiken haben und in der Lage sein, Spiele einzugeben. Wie sie in den Spielen abschneiden, hängt von ihren Statistiken ab. Wenn die Spiele festgelegt sind, wird die Anwendung alle aktuellen Statistiken des Benutzers abrufen und ihre Punkte ermitteln, um zu sehen, wer gewinnt.

Nachdem ein Spiel vorbei ist, möchte ich, dass Benutzer vergangene Spiele anzeigen können. Dabei entsteht das Problem, wenn ich anzeigen möchte, was die Punkte der Teilnehmer zum Zeitpunkt des Spiels waren. Ich würde denken, es wäre akzeptabel, ein Array in folgender Struktur zu speichern:

array(
 array(Benutzername, Punkte),
 array(Benutzername, Punkte),
 usw.
)

Die Daten zu normalisieren wäre normalerweise die beste Praxis, aber in dieser Situation:

• Es können zwischen 2 und 25 Teilnehmer in einem Spiel sein.
• Die Daten werden niemals aktualisiert, sondern nur gelesen.
• Ich denke, dass es sinnvoll ist, die Daten in einer Array-Struktur in der Datenbank zu haben, um Zeit zu sparen, die ich sonst damit verbringen müsste, ein Array in meinem Backend-Code zu konstruieren.
• BEARBEITEN: Die Daten sind nicht dauerhaft. Spielprotokolle werden 7 Tage nach Spielende gelöscht.

Kann mir jemand sagen, ob dieses Lösung Probleme verursachen wird?

---

BEARBEITEN

Ich würde die Daten nach der Serialisierung des Arrays speichern, sodass ich in meiner Datenbank eine Tabelle namens 'matches' haben würde und sie hätte eine Spalte namens 'results'.

Die Zeilen für diese Spalte würden serialisierte Arrays enthalten. Wenn das Array beispielsweise so aussähe:

$array["a"] = "Foo";
$array["b"] = "Bar";
$array["c"] = "Baz";
$array["d"] = "Wom";

Dann würde die Zeile in der Datenbank so aussehen:

a:4:{s:1:"a";s:3:"Foo";s:1:"b";s:3:"Bar";s:1:"c";s:3:"Baz";s:1:"d";s:3:"Wom";}

Answer 1

Diese Lösung würde kurzfristig keine Probleme darstellen - aber wenn Sie später Funktionalitäten hinzufügen möchten, um alle Spiele anzuzeigen, die ein Benutzer gespielt hat, oder ihre am besten bewerteten Spiele... das Daten in einem von SQL nicht zugänglichen Array würde es Ihnen nicht erlauben, diese Funktionen zu haben.

Ich denke, eine Tabelle wie diese wäre perfekt:

CREATE TABLE game_scores(
    id int AUTO_INCREMENT NOT NULL PRIMARY KEY,
    game_id int,
    user_id int,
    final_score int,
    KEY(game_id),KEY(user_id)
)

Am Ende jedes Spiels würden Sie einfach eine Zeile für jeden Benutzer einfügen, der in dieser Runde gespielt hat, mit ihrer entsprechenden Punktzahl und der Spiel-ID. Später könnten Sie alle Punktzahlen für ein bestimmtes Spiel auswählen:

SELECT * FROM game_scores WHERE game_id=?

... oder alle Punktzahlen von einem bestimmten Benutzer anzeigen:

SELECT * FROM game_scores WHERE user_id=?

usw. Viel Spaß damit!

Answer 2

Wenn Sie wirklich zu den Anwendungsfällen, die Sie in der Frage erläutert haben, sowie zu der Qualifikation in Ihrem Kommentar an Sean Johnson verpflichtet sind, sehe ich keine Probleme mit Ihrem Ansatz.

Ich möchte das eventuell noch dadurch qualifizieren, dass Sie die Daten normalisieren, wenn Sie glauben, dass es eine Chance gibt, dass Sie historische Informationen nutzen möchten. Es könnte also Sinn machen, ein Array als eine Art Cache in die Datenbank zu schreiben. Mit anderen Worten, speichern Sie es in beiden Formaten, aber der Hauptteil des von Ihnen skizzierten Anwendungsfalls würde nur das Array-Format abrufen, aber Sie hätten die Daten immer noch in einer abfragbaren Form, wenn Sie sie jemals benötigen.