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

[DefconDev]

Es tut mir leid wenn ich vielleicht etwas patzig herüber komme, aber ich bin gerade etwas verzweifelt.
Die Teams werden ZUFÄLLIG zusammen gewürfelt aber natürlich können gleiche Teams durch Zufall entstehen. Es gibt keine Saison, daher können bei 20 Spielern über Jahre hinweg immer wieder mal die selben Teams entstehen.

So ich habe es mal visualisiert nach der svg von Pikto:



Die gelb markierten Zeilen sind zwar die selben Teams haben aber andere TeamIDs.
Jetzt möchte ich später eine Abfrage erstellen die es mir ermöglicht herauszufinden mit welchen Teammitglieder der Spieler Peter am erfolgreichsten zusammengespielt hat. Also Vergleiche wie Spieler Peter war am erfolgreichsten mit Klaus im 2er Team. Nächste Abfrage, Spieler Peter war in einem 3er Team am erfolgreichsten mit Klaus und Basti. Also ich will Mengen miteinander vergleichen. Und in Piktos Tabellen-Konstrukt sehe ich nicht die Möglichkeit eine solche Abfrage zu gestalten. Hinzu kommt noch dass KlausPeter(TeamID3) nicht eindeutig sind, es kann durchaus vorkommen dass es zwei Peters als Spieler gibt.

Daher hatte ich die Idee im Eingangspost, ein Array(aus den SpielerIDs) zu serialisieren und abzulegen und dann bei Bedarf mit Programmcode es wieder derialisieren und die IDs der Spieler als Vergleich verwende weil die eindeutig sind.

Ergänzung (3. November 2017)

Aber mal so am Rande, ein Team lässt sich auch durch die PlayerID-Kombinationen prüfen, welche dann auch eindeutig wären.

*edit* Sprich: Erst prüfen ob es ein Team mit der Kobination aus diesen SpielerIDs schon gibt und falls nicht, dann kann ja ein neues generiert werden.

Das ist der Kern dessen warum ich hier bin. Wie lässt sich das prüfen? Mir fällt keine Methode ein, als aus den SpielerIDs einen Hash zu generieren(oder serialisierung) und den in der Team-Tabelle abzugleichen. Ich wäre dir verbunden wenn du das näher ausführen könntest.

 

[Enurian]

Wie oft muss man das denn noch wiederholen? Es ist das Problem deiner Anwendung, die Teams da vernünftig einzufügen. Wenn eine Kombination von Spielern ein einzigartiges Team sein sollen, kannst du das über Primary Keys einschränken. Ggf. dann die Relation Team -> Spieler in eine eigene Tabelle auslagern und nur noch Teams mit Spieltagen verknüpfen. Musst du dann aber auch entsprechend beim Befüllen beachten.
Man kann dir hier nichts fertig auftischen, weil du nicht alle Rahmenbedingungen nennst. Außerdem ist eine Eigenleistung auch angebracht, hier wurden schon genug Tipps gegeben, um das alleine zu Ende zu bringen.

Nächster Punkt IDs: Du hast doch die Spieler-IDs in der Datenbank. Teams haben ebenfalls IDs. Warum sollen dann Namen einzigartig sein müssen? Sie sind es nicht.
Abfragen: Alle deine Beispiele lassen sich über die Struktur lösen. Es muss natürlich noch irgendwo diese geheime "Erfolgsvariable" hinterlegt werden. Du musst dafür nur deine Tabellen zusammen-joinen, mit Gruppierungen, Summierungen usw. kommst du dann zum Ziel.

 

[ayngush]

Ohne Anspruch auf Vollständigkeit

Teams (TeamID, TeamName, ...)
Spieler (SpielerID, SpielerName, ...)
Spieltage (SpieltagID, SpieltagDatum, ...)
SpielerTeam (SpielerID, TeamID)
Spiel (SpielID, SpieltagID, TeamID, Punkte, ...)

 

[Piktogramm]

Ich verstehe nicht, wieso du die Teams unbedingt benennen willst. Mehr als Team A und B brauchst du doch nicht (insofern braucht es die Tabelle "Team" nicht einmal zwingend). Die Zusammenstellung der Teams zum Spieltag X steht dann ja in der Tabelle "Spiel" eindeutig drinnen.

Die Zusammenstellung der Teams dann nochmal redundant in einer Tabelle abzulegen zeigt nur, dass du das mit der Normalisierung nicht im Ansatz verstanden hast.

 

[DefconDev]

Ich verstehe nicht, wieso du die Teams unbedingt benennen willst. Mehr als Team A und B brauchst du doch nicht (insofern braucht es die Tabelle "Team" nicht einmal zwingend). Die Zusammenstellung der Teams zum Spieltag X steht dann ja in der Tabelle "Spiel" eindeutig drinnen.

Die Zusammenstellung der Teams dann nochmal redundant in einer Tabelle abzulegen zeigt nur, dass du das mit der Normalisierung nicht im Ansatz verstanden hast.

Das hast du mir doch empfohlen? Die Relation Team ist aus deinem svg. Oder meinst du den User ayngush?

@Enurian, was für Rahmenbedingungen fehlen dir denn?

Erfolg im Sinne welche Teamkonstellation die meisten Siege eingefahren hat.

EDIT:

Meine Idee war eher solcher Natur, wobei die unterste Variante wie im Startpost erwähnt eher eine Alternative sucht.

 

[Piktogramm]

So ein UML sagt nur bedingt etwas Inhalt der Tabellen aus. Es braucht halt ein Merkmal / eine Spalte um gegeneinander spielende Teams unterscheiden zu können. Dabei ist das Minimum der zu unterscheidenden Teams die Anzahl an Teams die gleichzeitig gegeneinander spielen und das Maximum eine kombinatorische Explosion (<- google) bei der alle potentiell möglichen Spielerbpaarungen enthalten sind.
Die Wahl fällt leicht.

 

[Enurian]

@Enurian, was für Rahmenbedingungen fehlen dir denn?

EDIT:
Meine Idee war eher solcher Natur, wobei die unterste Variante wie im Startpost erwähnt eher eine Alternative sucht.

Anhang anzeigen 650020

Habe ich doch bereits auf der letzten Seite geschrieben: Es weiß niemand, wie das alles ablaufen soll und was du eigentlich willst (ganz konkret! "Spieler spielen in Teams" reicht da nicht). Ohne diese Informationen ist das hier ein Ratespiel.
Dein Anhang schließt den Kreis jetzt wieder... das ist doch genau das, was dir seit 3 Seiten versucht wird auszureden. Eine Relation zwischen Team und Spieler (hier jetzt nur die IDs) wird so nicht dargestellt, sondern mit einer Tabelle
TeamID - SpielerID
und dann für jeden Spieler in jedem Team einen Datensatz. Eine klassische n:m Relation.

 

[DefconDev]

Das ist mir bewusst dass es so nicht dargestellt wird, deswegen bin ich bei euch ;-)

Aber bevor ich eure Gemüter weiter strapaziere, werde ich heute Abend nochmal eine kleine SQL-Lite Datenbank hochladen wie sie Pikto erstelllt hat mit den von mir genutzten Abfragen, vielleicht wird dann deutlicher wo mein Problem liegt. Ich glaube nämlich mir fehlt die passende Abfrage.

 

[ayngush]

Ich verstehe nicht, wieso du die Teams unbedingt benennen willst. Mehr als Team A und B brauchst du doch nicht ...

Und "A" und "B", die es ja nur braucht, stehen dann bitte wo in der Datenbank? Oder soll das wieder die Anwendung auswürfeln?
Ich glaube hier im Thread gibt es einige, die Datenmodellierung und Datenbankdesign nicht verstehen aber dazu zähle ich mich nicht unbedingt.
Abgesehen davon, dass ich da so ein paar Zettel (von CERT.it, Oracle & Microsoft) an der Wand hängen habe, die ganz klar belegen, dass ich darauf "etwas" Spezialisiert bin und so... mache ich so etwas schon "ein paar Tage".

Mein Problem ist hier eher, dass die Ausgangssituation nicht vernünftig zusammenhängend geschildert wird, man sich im Verlauf des Threads mehrfach widerspricht, keiner eindeutigen Semantik folgt und generell kreuz und quer labert.

Wenn man ein Datenmodell erstellen möchte, fängt man mit dem Modellieren an und nicht mit dem Ausdiskutieren von Entitäten. Eine mögliche Reihenfolge dafür wäre:

0. Computer beiseite legen
1. Vorhaben genau aufschreiben und präzise beschreiben. Auf gleichen Wortlaut und Worttreue achten.
1.5 (optional) EPK / BPMN erstellen, um die Logik im Vorhaben darzustellen und dadurch eventuelle Probleme im Gesamtmodell aufzudecken
2. UML Use Case Diagramm erstellen (Dabei werden auch die unterschiedlichen Rollen im System ermittelt und definiert)
3. ER-Modell erstellen
3.5 im ER-Modell die Kardinalitäten bestimmen
4. UML Class Diagramm erstellen
5. Relationenmodell erzeugen
6. Computer wieder hervorholen
7. Jetzt die Datenbank anlegen...

Edit: In die 3NF rutscht man dadurch nahezu automatisch. Falls nicht, war Schritt 1 scheiße -> nochmal von vorne. Falls das beim 3. Anlauf immer noch nicht klappt: Finger weg von Datenbanken, lieber was mit Holzbearbeitung suchen.

 

[Limit]

Da leider einige wesentlichen Informationen fehlen (z.B. die Art des Spiels oder woher die Teamnamen kommen) treffe ich einfach mal ein paar Annahmen (Teamnamen werden aus Namen der Spieler generiert und das Ergebnis eines Spiels ist einfach nur eine Punktzahl für jedes Team). Zudem nehme ich an, dass die Spieler eines Teams sortiert werden, bevor sie in die Datenbank eingetragen werden. Sollten diese Annahmen nicht zutreffen, dann bitte die fehlenden Informationen ergänzen.

Im Prinzip kann man das ganze auf die Tabelle Spieltag reduzieren:

Spieltag(datum, spiel, sp1, sp2, sp3, sp4, punkte)

"spiel" ist dabei einfach eine forlaufende Nummer, die für jede generierte Paarung um eins erhöht wird, "sp1" bis "sp4" sind die Spielernamen eines Teams und "punkte" die Punkte die das Team in diesem Spiel erreicht hat.

Die besten Teams ließen sich dann z.B. einfach wie folgt ermitteln:

select sp1, sp2, sp3, sp4, sum(punkte) from Spieltag group by sp1, sp2, sp3, sp4 order by sum(punkte) desc;

Die einzelnen Spiele ließen sich wie folgt ermitteln:

select a.datum, a.sp1, a.sp2, a.sp3, a.sp4, b.sp1, b.sp2, b.sp3, b.sp4, a.punkte, b.punkte from spieltag as a, spieltag as b where a.spiel == b.spiel and a.sp1 < b.sp1 order by a.datum;

 

[Piktogramm]

@ayngush

Das die Beschreibung von Hades85 nicht taugt, da bin ich bei dir

Team A bzw. B steht in der Tabelle Team (siehe Diagramm aus Post #17)*. Soweit ich Hades verstehe sind die Teams ja keine fixen Mannschaften wie im Fußball sondern einfach temporäre Zuordnungen von Einzelpersonen die in dieser temporären Truppe gegeneinander spielen. Solang keine weiteren Anforderungen an die Unterscheidbarkeit etwaiger Teams gestellt werden reicht es damit eine simple Mannschaftsunterscheidung für jedes Spiel zu haben.


*Wobei die Tabelle "Team" unnötig ist. Es würde eine Spalte "team" in der Tabelle "Spiel" ausreichen die eine entsprechende A/B Unterscheidung ermöglicht. Das ist für Dritte die den Spaß nachvollziehen sollen nur meist schwerer verständlich und eine extra Tabelle "Team" erlaubt es auch Bezeichner zu verwenden die menschlich verständlich sind. Wenn die Mannschaften zum Beispiel farbige Trikots bekommen kann die Teambezeichnung entsprechend auch rot / blau heißen. Das verstehen die Meisten dann auch ohne geschriebene Doku auf den ersten Blick.

 

[The Ripper]

Ohne Anspruch auf Vollständigkeit

Teams (TeamID, TeamName, ...)
Spieler (SpielerID, SpielerName, ...)
Spieltage (SpieltagID, SpieltagDatum, ...)
SpielerTeam (SpielerID, TeamID)
Spiel (SpielID, SpieltagID, TeamID, Punkte, ...)

​Ja benutz bitte das (wobei du den Teamnamen auch weglassen kannst).
​Natürlich brauchst du bei Spiel aber zwei TeamIDs (es spielen ja immer zwei Teams gegeneinander).

​Wenn du zum Spieltag nur das Datum gespeichert haben möchtest, kannst du dies auch direkt im Spiel eintragen statt der SpieltagID.
​
​Teams kannst du eventuell auch wegrationalisieren, wenn du keinen Teamnamen benötigst.

​Umgesetzt würde das rauskommen:

Spieler (SpielerID, SpielerName, ...)
SpielerTeam (SpielerID, TeamID)
Spiel (SpielID, TeamID1, TeamID2, Datum, Punkte, ...)
​

​Es gibt Spieler mit Spielernamen und eventuell weiteren Eigenschaften: Spieler
​Jeder Spieler ist in einer beliebigen Anzahl von Teams, wobei ein Spieler nicht mehr als einmal im gleichen Team sein kann: SpielerTeam
Jeden Tag können beliebig viele Teampare gegeneinander spielen, wobei ein Team auch öfter gegen das gleiche Team spielen kann. Pro Spiel wird Datum, Punkte und ggf. weitere Eigenschaften gespeichert: Spiel....

 

[Piktogramm]

@The Ripper
Deine TeamID sicher Spielern zuzuordnen muss bei dir *irgendwoher* kommen. Das wird ein großes Vergnügen

@ayngush
Analog, die Vergabe von eindeutigen IDs für Teams als Zusammenstellung von Spielern braucht auch Informationen, deren Vorhandensein Hades nicht angegeben hat (oder hab ich es überlesen?). Wobei ja die Vergabe von eindeutigen Zuordnungen aufgrund nicht vorhandener Daten immer eklig wird.

 

[The Ripper]

Deine TeamID sicher Spielern zuzuordnen muss bei dir *irgendwoher* kommen. Das wird ein großes Vergnügen
​

​Ja eventuell wäre tatsächlich eine weitere Tabelle nur mit einer autoincrement Spalte hilfreich, aber nicht notwendig:
Beim Anlegen eines neuen Teams (vorher überprüfen, ob das Team schon existiert) einfach das Maximum der TeamID aus der Tabelle extrahieren und die Spieler mit dem Maximum+1 einfügen

Analog, die Vergabe von eindeutigen IDs für Teams als Zusammenstellung von Spielern braucht auch Informationen, deren Vorhandensein Hades nicht angegeben hat (oder hab ich es überlesen?). Wobei ja die Vergabe von eindeutigen Zuordnungen aufgrund nicht vorhandener Daten immer eklig wird.​

​Ein Team definiert sich durch die Spieler, die in ihm sind.
​In meinem Beispiel also den SpielerIDs, die eine TeamID besitzt.

 

[ayngush]

TeamID ist ein Autoinkrement, welches beim Erstellen des Teams definiert wird. TeamName könnte auch ein Random-Wert aus einer Wörterliste oder so sein, damit kann man dann noch lustige Namen zusammen würfeln (Rosa Glücksbärchen vs. Green Ninjas oder so...)
Ich schauen dabei auch immer ein wenig auf die Möglichkeiten der Erweiterung. Braucht man einen Teamnamen für das System nicht unbedingt am Anfang zum Start, geschenkt. Will man mal eine "ewige Bestenliste" führen, macht es Sinn die Teams zu benennen usw.

Am Ende ist es für das System egal, ob das Team einen Namen hat oder nicht, die Spiele können auch ohne Namen ausgewertet werden. Es ist nur einfacher an einen brauchbaren Schlüssel zu kommen, wenn man einen Autoinkrement dafür verwendet. Und da Team generell eine Entität ist, die in einer definierten Beziehung zu Spielern und Spieltagen und "Spieltagpaarungen" steh(en muss), macht es "durchaus Sinn" (ist in der 3NF erforderlich, transitive Abhängigkeit) das einzeln zu führen. Aus der Erfahrung heraus: Spart nicht mit Datumswerten. Ein TeamCreationDate schadet zukünftig nicht. Ein PlayerCreationDate auch nicht usw. Edit: Meine damit, dass die "Teams" Entität auch aus "TeamID (PK) und TeamCreationDate" bestehen kann. Dann hat das Team keinen Namen, aber eine Eindeutige ID, die beim Ertsellen eines Teams angelegt wird. Bei einem Spiel, wenn es öffentlich wird, wird es auch notwendig sein Teams zu sperren usw. solche Flags gehören da dann genau so hinein, wie Teambasierende Handicaps uvm.

Wie gesagt, wenn man das ordentlich modellieren möchte, muss man sich die Mühe machen, und das kann einen auch niemand abnehmen, und sein gesamtes Vorhaben präzise beschrieben. Alles andere können wir jetzt versuchen über Seiten hinweg zusammen zu raten, wird aber wenig Zielführend sein.

Die Basics, die dafür notwendig sind, wurden jetzt ja schon mehrfach angesprochen, allen voran die 3NF. Wer das Prinzip dabei generell nicht verstanden hat, vor allem scheitert es hier am Verständnis für die transitive Abhängigkeit, der wird auch im leben keine ordentliche Datenbank modelliert bekommen. Aber Anfangen wird so etwas immer mit einem präzise formulierten Vorhaben - und daran scheitert es gerade.


Edit2:

Teams kannst du eventuell auch wegrationalisieren, wenn du keinen Teamnamen benötigst.

Nein, kann man leider nicht ohne wieder in der 2. NF zu landen.
Spiel darf auch keine TeamID1 und TeamID2 beinhalten, da das wieder ein Verstoß gegen die 3. NF ist.
Man muss das System dann um den kompetitiven Charakter erweitern (sagte ja ohne Anspruch auf Vollständigkeit) und aus den Spielen pro Spieltag und Team noch "Spielpaarungen" machen.

Spielpaarungen: SpielpaarungID, SpielID

Jetzt kommt noch erschweren dazu, dass wir wieder nur annehmen, oder Stand es hier schon, dass immer ein Team gegen genau ein anderes Team spielt. Was ist mit Team A und Team B gegen Team C und Team D oder Team A vs. Team B vs. Team C usw. Deswegen hatte ich die "Spielpaarungen" nicht weiter ausgeführt.

 

[DefconDev]

Wie gesagt bevor die Gemüter noch weiter strapaziert werden und ein paar wenige sich über meine Unzulänglichkeiten weiter echauffieren, räume ich das Feld. Ich bedanke mich trotzdem für den ganzen Input, besonders für die ganzen Praxisbeispiele, hier haben sich alle wirklich ins Zeug gelegt obwohl ich ein schwieriger Patient gewesen bin.

Abschließend sei gesagt, es hat funktioniert mit euren Anweisungen, ich war zu fixiert darauf es anders zu lösen.

 

[The Ripper]

Spiel darf auch keine TeamID1 und TeamID2 beinhalten, da das wieder ein Verstoß gegen die 3. NF ist.

​Wenn jedes Spiel immer genau zwei Teams hat?

Nein, kann man leider nicht ohne wieder in der 2. NF zu landen.

​Du kannst dir gern eine zusätzliche Tabelle denken. An der bestehenden Tabelle ändert sich nichts. Letztendlich Geschmackssache.

​Es geht übrigens nicht darum einen Normalisierungswettbewerb zu gewinnen.​