keine Idee wegen Nummerierung pro Saison

  • Themenstarter Themenstarter thegamehhh
  • Beginndatum Beginndatum
T

thegamehhh

Aktuell bin ich dabei mein eigenes Fußball-Skript umzuschreiben in CodeIgniter. Speziell handelt es sich um die Tabelle für die Ergebnisse. Da es sich dabei um die 1.Bundesliga handelt, möchte ich nicht nur nach den Jahren die Ergebnisse speichern.

Dies ist das Ergebnis eines Teils der Datenbank wie ich sie als Struktur angelegt habe.
306 (matchid), 306 (number of the match), 2012 (seasonyear), 34 (matchday)
307, 1, 2013, 1
....
612, 306, 2013, 34
613, 1, 2014, 1

Da eine Saison in der Bundesliga 306 Spiele hat, möchte ich das Skript gern so anlegen, dass die "matchid" immer fortlaufend ist und sobald eine neue Saison angelegt wird, die Spalte "number of the match" von vorne beginnt. In einer weiteren Tabelle werden bereits anhand der Anzahl der Mannschaften und Spieltage, die Anzahl der Spiele errechnet.

In Zusammenhang mit dieser Tabelle möchte ich gern eine Kontrollfunktion integrieren, die es nicht gestattet mehr als 306 Spiele pro Saison in die Ergebnis-Tabelle zu integrieren.

Ich hoffe, durch euch kann ich nachvollziehen, wie die Nummerierung der Spalte "number of the match" mit einer jeden Saison von neuen beginnen kann.
 
Hallo,

ich konnte leider nicht ganz deine Frage rauslesen.
Wenn deine Frage war, wie du die Spielanzahl pro Saison überprüfen kannst, dann würde ich das so machen:
SQL: 
-- Deine Tabelle habe ich mal 'matches' genannt
-- xyzw = 2013/2014/...
SELECT COUNT(*) FROM matches WHERE seasonyear = 'xyzw'
Wenn die Anzahl größer als 306 ist, dann gestatte kein weiteres Hinzufügen von Spielen.
 
Das was du herausgelesen hast, ist mein Zusatz den ich einbringen möchte.

Ich möchte, wenn die ID bei 306 angekommen ist, dass bei 307 nicht auch die ID für das Spiel mit 307 weiterläuft, sondern mit 1 wieder beginnend. Wie in meinem Beispiel oben.
306 (matchid), 306 (number of the match), 2012 (seasonyear), 34 (matchday)
307, 1, 2013, 1
....
612, 306, 2013, 34
613, 1, 2014, 1
 
Die MatchId brauchst du dafür nicht. Du zählst einfach wie viele Spiele es schon in der Saison gegeben hat (COUNT).
Wenn Count <306 ist dann ist numberOfMatch = Count +1 sonst numberOfMatch=1 und Saison=Saison+1 bzw. du gibst einen Fehler aus.
 
Ich kann eine konkrete Frage auch noch nicht so recht erkennen. Das Gerechne mit dem Primärschlüssel würde ich aber lassen. Das ist in Datenbanken quasi nie eine gute Idee.

Ich würde auch aufpassen, das alles nicht zu „statisch“ anzulegen, also im Code zu sehr auf konkrete Zahlen wie 306 abzuheben. Das macht deinen Code schlecht erweiterbar.

Brauchst du denn am Ende wirklich ein Nutzer-Interface, in das du Spiele einträgst, wobei das Interface automatisch alle 306 Einträge eine neue Saison beginnt? Ich kann mir dafür keinen praktischen Nutzen denken.
 
Mir geht es darum, dass der Spielplan den ich in die Datenbank eintrage, mit dem der DFL gleich ist von der Reihenfolge. Wenn ihr euch den Link anschaut, hat jedes Spiel auch eine eigene ID. Da ich auch ganz alte Spiele nach und nach in die Datenbank eintragen möchte, möchte ich einfach angeben, welches Spiel welche Nr. hatte, damit eine korrekte Reihenfolge entsteht. Du kannst auch nicht immer davon ausgehen, dass du bei einem alten Spiel z.B. aus der Entstehungszeit des Vereins ein Datum finden wirst und somit nicht danach sortieren kannst.

Desweiteren möchte ich diese Kenntnisse, die ich in dieser Sache erlange, in ein anderes Projekt mit einfließen lassen, da dies ein ähnliches sein wird, was aber nicht mit Fußball zu tun hat.
 
Wenn deine Daten aus diesen Spielplänen stammen, dann kannst du ja nicht mehr als 306 Spiele pro Saison haben und musst dementsprechend auch nicht darauf prüfen.
Wenn es dir vor allem auf die Festlegung der Reihenfolge ankommt: Warum legst du deine Spalten nicht zu einer zusammen? Wenn du MatchId nicht automatisch vergibst sondern sie aus den Nummern zusammenbaust kannst du deine Tabelle einfach nach der MatchId sortieren und hast sie Chronologisch geordnet.
Vorschlag MatchId= JJJJTTSSS
Wobei JJJJ das 4 stellige Saison Jahr ist, TT der Spieltag und SSS die Spielnummer. Mit Substr() kannst du die Einträge trotzdem noch nach Saison, Spieltag oder Spielnummer filtern.
 
Eine Zusammenlegung der Daten würde ich nicht empfehlen.
Eine Filterung / Sortierung der Daten sollte bei der Ausgabe oder beim Abfragen erfolgen, nicht mein Eingeben!
Wenn eine Sortierung mit reinen SQL-Mitteln nicht möglich ist, kannst du immer noch auf der Klientseite (z. B. PHP) die Sortierung ausführen.

Mir fällt gerade noch eine Idee ein: generiere die MatchId, wie von ikosaeder beschrieben, mit einer SQL Procedure, die bei jedem Update und Einfügen eines Datensatzes ausgeführt wird. Somit erhälst du dir die Daten, erhälst aber zugleich ein Mittel, das eine einfache Sortierung ermöglicht. Allerdings muss man hier zwischen einer einfachen Sortiermöglichkeit und einer Datenredundanz abwägen.
 
@ComFreek: Du hast meine Idee nicht ganz verstanden. Es ist egal in welcher Reihenfolge die Daten eingegeben werden. Ein Order by MatchId liefert automatisch eine chronologische Reihefolge. Ich habe lediglich aus 4 Spalten 1 gemacht. Die Datenredundanz wurde dabei verringert, denn statt MatchId und Spielnummer braucht man nur noch die MatchId und hat trotzdem alle Informationen.
Beispiel: Das 1. Spiel am 30 Spieltag 2012 wird zuerst eingegeben: MatchiD 1 = 201230001
Dann wird das 3. Spiel am 1 Spieltag 1966 eingegeben: MatchId 2 = 196601003
Zum Schluß das 300 Spiel vom 12 Spieltag 2000 MatchID 3 = 200012300
Wenn man jetzt sortiert erhält man die richtige Reihenfolge: 2 3 1.
Und alles nur mit simplen SQL-Befehlen.
 
@ikosaeder Genau so habe ich es verstanden gehabt ;) Ich wollte anmerken, dass es bei deiner Variante schwieriger wird, einige Anfragen zu stellen. Ein Beispiel wäre ein Query, welches die Anzahl der Tore jener Spiele zurückgibt, die zwischen dem 10. und 20. Spieltag eines Schaltjahrs stattfanden. Ich gebe zu, dass dieses Beispiel freilich ein wenig weit hergeholt ist, jedoch ist damit veranschaulicht, dass das Zusammenpacken der Daten in einen String gravierende Nachteile haben kann.

Ich weiß nicht, in welchem Ausmaße (an Komplexität) thegamehhh Anfragen an die DB schicken will. Deine Variante kann durchaus die einfachere sein, aber wenn Anfragen in der Art, die ich oben erwähnt habe, gestellt werden müssen, ist deine Variante nachteilhaft.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück