[Datenbank] Array in einer Spalte ablegen oder wie vorgehen?

DefconDev

Commander
Registriert
Jan. 2008
Beiträge
2.540
Hallo zusammen,

"simple" Situation liegt vor.

Ein Team kann aus 2-4 Spieler bestehen, variiert also pro Spiel.

Tabelle Spieltag sähe so aus:

SpieltagID____TeamID
0 ___________0
1 ___________1

Tabelle Team

TeamID____SpielerIDs
0_________[0,4,7]
1_________[1,2,3]


Wichtig ist, dass ich mit MySQL eine Abfrage erstellen kann mit den SpielerIDs. Also eine Serialisierung der SpielerIDs z.B als String zu speichern ist das eine elegante Lösung?

Wie kann ich also eine Tabelle erstellen die unterschiedliche Anzahl an Spielern pro Team zusammenfasst ohne das Spalten frei bleiben, sollte man auf die Idee kommen pro Spieler eine Spalte zu erstellen?
 
Zuletzt bearbeitet:
Jo, SpielerIDs als PrimaryKey, TeamID als ForeignKey.

Code:
+------------+--------+
| Spieler ID | TeamID |
+------------+--------+
|          1 |      1 |
|          2 |      2 |
|          3 |      1 |
|          4 |      2 |
|          5 |      2 |
+------------+--------+
 
Zuletzt bearbeitet:
ID TeamId PlayerId

So oder was meint ihr?

Edit:

Also der PrimaryKey macht aber keinen Sinn, denn die die Teams verändern sich pro Spieltag jedes Mal. Und TeamID wird auch permanent nach oben gezählt, denn es gibt keine gleichen Teams.
 
Zuletzt bearbeitet:
Ist denn die Zuordnung der Spieler zu den Teams fest oder kann die von Spieltag zu Spieltag abweichen?
 
Meine Frage war anscheinend etwas ungenau. Kann Spieler x an Spieltag 1 in Team a und am Spieltag 2 in Team b spielen? Oder ist Spieler x immer im selben Team, auch wenn er nicht immer aufgestellt ist?

Das macht einen großen Unterschied. Einmal wäre es eine 1:n Beziehung zwischen Team und Spieler (Lösungsbeispiel oben von Sturm91), das andere wäre eine m:n Beziehung, die man mit einer separaten Relationstabelle abbilden kann.

Was meinst Du mit es gibt keine gleichen Teams? Dann ist eventuell eine Team-Tabelle überflüssig? Wenn Du ein praktisches Beispiel nennen würdest, wäre die Analyse einfacher ...
 
Ich habe dich schon richtig verstanden. Sagen wir es gibt 20 Spieler, jeder dieser Spieler kann ein Team mit einem anderen bilden pro Spieltag. Und wie gesagt ein Team kann aus 2 bis 4 Spieler bestehen. Also am Spieltag 1 spielen Spieler 1,2,3 gegen 4,5,6, Spieltag 2 spielen Spieler 2,4,6 gegen 1,3,5. Spieltag 3 könnten dann Spieler 10, 1 gegen Spieler 8,9,10.

Ich habe mich ungenau ausgedrückt, es ist durchaus möglich das die selben Teams wieder entstehen oder zumindest. Teilmengen. Und da lag bisher mein Problem, wenn ich später eine Relation erstelle ist die Abfrage für mich jedenfalls nicht möglich gewesen ohne Schleifenkonstrukt(nur SQL) heraus zu finden welche Spieler miteinander das erfolgreichste Team gebildet haben, zumindest, wenn man jedem Spieler ein Zeile gibt und mit FK-Schlüssel arbeitet für die Teams.
 
Zuletzt bearbeitet:
Dann halt Spieltag als Foreign Key mit aufnehmen

Auswertungen kannst du dann über group by / count machen
 
Das Problem welches ich sehe, ich müsste für jede erdenkliche Kombination eines Teams eine Zeile erstellen in einer separaten Tabelle. Sobald ich einen neuen Spieler erstellen müssten wieder komplett neue Kombinationen abgelegt werden, empfinde ich als ziemlich umständlich. Gibt es da keine andere Lösung?
 
Das was du in deinem Ausgangspost vorhast verletzt 1NF (keine listenartigen Wiederholungen) und wird sehr schnell sehr umständlich und insbesondere fehleranfällig - in anderen Foren vormuliert man das ein wenig nachdrücklicher ;).

Lies dich am besten mal ins Thema ein und versuche die Vorteile eines "guten" bzw. "korrekten" Datenmodells und damit Datenbank-Entwurfes nachzuvollziehen.
 
Ich hatte auch nicht vor das als Array abzuspeichern, daher bin ich hier für Input und nicht für eine Belehrungsstunde. Andere Ansätze von mir werden auch verneint, aber ein Vorschlag wie das abzubilden ist kommt nicht vor.
 
Ja, weil es halt nicht richtig ist.
Gibt nun mal Regeln, die man grad bei Datenbanken beachten sollte, dass man sich das Leben nicht schwerer macht, als es ohnehin schon ist.

Code:
+-----------------+------------------+----------------+--------------------+
| ID(PK,AI,UQ,NN) | Player_ID(FK,NN) | Team_ID(FK,NN) | Spieltag_ID(FK,NN) |
+-----------------+------------------+----------------+--------------------+
|               0 |                1 |              1 |                  1 |
|               1 |                1 |              2 |                  2 |
|               2 |                1 |              3 |                  3 |
|               3 |                2 |              1 |                  2 |
|               4 |                2 |              2 |                  3 |
|               5 |                3 |              1 |                  1 |
|               6 |                3 |              2 |                  3 |
|               7 |                4 |              3 |                  2 |
+-----------------+------------------+----------------+--------------------+

PK - Primary Key
FK - Foreign Key
AI - Auto Increment
UQ - Unique
NN - Not Null


Das wurde dir paar Posts weiter oben vorgeschlagen.
​Ergibt von den Sachen her am meisten Sinn.
 
Erst einmal ein Dank für die visuelle Darstellung, aber ich glaube mein Problem wird nicht deutlich genug von mir beschrieben.

Die Relation Team müsste dann so aussehen:

ID____TeamID____PlayerID
0_____1_________1
1_____1_________2
2_____2_________1
3_____2_________2
4_____2_________3
...
10____4_________1
11____4_________3

Das geht so weit bis alle Kombinationen durch sind und sobald ich einen neuen Spieler einpflege muss ich etliche neue Einträge generieren.
 
Was ist denn nun das Problem? Du möchtest nicht zuviele Einträge generieren? Ist der Speicherplatz so arg vom Serveradmin begrenzt?
 
Das was du beschreibst ist auch einfach Unfug. Wieso sollte jemand alle potentiellen Kombinationen Abspeichern?

Vorschlag:
Anhang anzeigen Diagram1.svg

Du musst ja nur die Informationen abspeichern die es so real auch gibt. Also welcher Spieler in welchem Spiel an welchem Spieltag in welchem Team gespielt hat.
 
Piktogramm schrieb:
Das was du beschreibst ist auch einfach Unfug. Wieso sollte jemand alle potentiellen Kombinationen Abspeichern?

Vorschlag:
Anhang anzeigen 649893

Du musst ja nur die Informationen abspeichern die es so real auch gibt. Also welcher Spieler in welchem Spiel an welchem Spieltag in welchem Team gespielt hat.

In deinem Konstrukt werden pro Spieltag immer 2 neue Teams in der Team Relation eingetragen.

Nochmal, es gibt keine festen Teams. Es gibt einen Spielerpool von 20 Spieler, jeder dieser Spieler kann mit min. einem weiteren Spieler ein Team bilden, gültig für ein Spiel. Im nächsten Spiel könnte dann die selben Spieler aus dem selben Team aus dem vorherigen Spiel als Gegner gegenüber stehen in zwei neuen Teams. Hinzu kommt das ein Team aus min. 2 Spielern oder maximal 4 Spieler bestehen kann.
 
Dann schau es dir nochmal an, dass lässt sich mit meinem Konstrukt recht gut abbilden.

Die lieben anderen Menschen hier haben ansonsten vollkommen recht. Du solltest die Grundlagen zur Normalisierung pauken! Denn selbst die Ansätze / Lösungen die dir gegeben werden scheinst du nicht zu verstehen.
 
Sparta8 schrieb:
Was ist denn nun das Problem? Du möchtest nicht zuviele Einträge generieren? Ist der Speicherplatz so arg vom Serveradmin begrenzt?

Nein, aber ich dachte es gibt eine andere Option, ich empfinde das als ziemlich umständlich, hinzu kommt das der spielerpool auf 100 anwächst, dann hat man schnell etliche Einträge.
 
Zurück
Oben