Trainingsverwaltung für Sportverein

Gladiator6

Erfahrenes Mitglied
Hallo

Zugegeben, der Titel ist ewas unglücklich gewählt, mir ist einfach nichts besseres eingefallen.

Ich betreibe eine Website für einen kleineren Sportverein. Ich habe mir überlegt eine art Traingsverwaltung auf Basis von PHP und MySql zu erstellen um in die Website einzubinden.

Idee:

Die Trainingsdaten sind in einer Datenbank gespeichert. Alle Vereinsmitglieder können sich einloggen, und bei allen Trainigsdaten angeben ob sie anwesend sein werden, oder eben abwesend!
Ziel wäre es also übersichtlich darstellen zu können wie viele und welche Personen an einem Datum anwesend sein werden.

Soweit so gut. Ich habe zumindest mit MySql noch nicht viel Erfahrung, und weiss deshalb auch nicht so genau wie man die Struktur der Datenbank für oben genanntes Projekt am besten aufbauen könnte?

Ist es sinnvoll für jedes Trainingsdatum eine eigene Tabelle zu haben?

Vielleicht kann mir da jemand ein paar Tipps geben?

Ich habe genügend Zeit, und werde die nächsten Wochen regelmässig daran arbeiten!
 
Zuletzt bearbeitet:
Grundlegend den Aufbau einer Datenbank ist die Struktur der Daten. Das heißt Du musst vom Speziellen zum Allgemeinen abstrahieren was gegeben sein soll. Zeichne Dir mal ein Diagramm mit Daten die Du benötigst (Usernamen, PasswortHash, Terminzeitraum, Ort, Gruppe, oder was auch immer) und kapsel sie in eigenen kleinen Gruppen (z..B. alle Daten die direkt Userrelevant sind in eine Gruppe). Dann könnte man -- hier nur grob ausgearbeitet -- zu folgenden Beispiel kommen:

Tabelle User:
- Usernamen
- UserID
- PasswortHash
- Gruppe

Tabelle Termine:
- TerminID
- Startzeitpunkt
- Endzeitpunkt
- Ort

Danach sollten beide Tabellen in Beziehung gesetzt werden. Da ein User mehrere Termine haben kann und ein Termin für mehere User gilt gibt es hier erstmal ein kleines Abbildungsproblem, denn relat. Datenbanken können das so nicht ohne weiteres darstellen. Es wird also ein Zusatzkonstrukt benötigt, welches die Zuordnung von User und Terminen beinhaltet. Das könnte dann so aussehen:

Tabelle UserTermine:
- UserID
- TerminID

Für dieses kleine und einfach Beispiel benötigst Du also schon 3 Tabellen -- jedenfalls falls Du sauber arbeiten und die Normalisierungsformen (http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html einhalten willst.
 
Wie ich die Verbindung zwischen Termin und Person herstellen muss/kann ist mir noch nicht ganz klar geworden!

Ich muss ja im Prinzip jeder TerminID die entsprechenden UserIDs zuordnen können, umgekehrt muss es auch möglich sein einer UserID die verschiedenen TerminIDs zuzuordnen!
 
Hi,

Ich muss ja im Prinzip jeder TerminID die entsprechenden UserIDs zuordnen können, umgekehrt muss es auch möglich sein einer UserID die verschiedenen TerminIDs zuzuordnen!

ja, genau dafür ist die Zuordnungstabelle UserTermine da:

Danach sollten beide Tabellen in Beziehung gesetzt werden. Da ein User mehrere Termine haben kann und ein Termin für mehere User gilt gibt es hier erstmal ein kleines Abbildungsproblem, denn relat. Datenbanken können das so nicht ohne weiteres darstellen. Es wird also ein Zusatzkonstrukt benötigt, welches die Zuordnung von User und Terminen beinhaltet. Das könnte dann so aussehen:

Tabelle UserTermine:
- UserID
- TerminID

LG
 
Ja das weiss ich schon, nur wie würde ich denn nun die Daten in diese Tabelle eintragen?

Ich kann mir doch die Tabelle UserTermine mit 2 Spalten vorstellen, UserID, und TerminID richtig?
 
Ich vermute die meinen in dieser 3ten Tabelle werden die Einträge "gesammelt" also wenn sich einer Für einen Termin einträgt wird dort eine neue reihe eingesetzt die auf einen User und einen termin zeigt.
Ich persönlich hätte das einfacher aber unprofessioneller gemacht.
In der Tabelle für die Termine eine spalte machen wo ich mit komata getrennt die id's der User reingeschrieben hätte und so hat man alle user die sich für das event eingetragen haben.
Aber ich glaube das entspricht nicht den Normalisierungsformen wie schon erwähnt wurde.
Bin da aber etwas Faul :P

MFG
Mark Paspirgilis
 
Hi,

Ich kann mir doch die Tabelle UserTermine mit 2 Spalten vorstellen, UserID, und TerminID richtig?

richtig. Wenn ein Benutzer sich für ein Training einträgt, erstellst Du dort eine neue Zeile mit der UserID und der TerminID der Trainingszeit.

Ich persönlich hätte das einfacher aber unprofessioneller gemacht.
In der Tabelle für die Termine eine spalte machen wo ich mit komata getrennt die id's der User reingeschrieben hätte und so hat man alle user die sich für das event eingetragen haben.

Und gleichzeitig würdest Du in der Usertabelle eine kommagetrennte Liste mit den Terminen pflegen müssen, oder wie wolltest Du sonst auf vernünftige Weise alle Termine zu einem User auslesen wollen?
Das ist ein typischer Anfängerfehler und in keinster Weise empfehlenswert. Und wenn Du faul bist, würde ich Dir raten, das DB-Design immer vernünftig zu gestalten, da Du Dir sonst mehr Probleme und damit Aufwand einhandelst, als Du vorher gespart hast.

LG
 
ich splitte die mir dann immer und pack die in arrays um damit vernünftig arbeiten zu können, hab ja auch gemeint dass das unprofessionell ist aber um ehrlich zu sein empfinde ich das einfacher aber ist ein "Fehler", da es nicht der norm entspricht aber ich bin da ein wenig unkonventioneller xD.
Deswegen wollte ich ihm nur mein beispiel geben falls es ihm hilft aber gleichzeitig davon abraten. Ich mache seit ca. 1,5 jahren MySQL/SQL es ist nicht lange aber ich habe schon ein wenig ehrfahrung, ich probiere nur immer gerne neue Techniken bzw. schlechtere Techniken die in besonderen Fällen die Arbeit erleichtern (man hat mehr arbeit in PHP aber weniger tabellen...), da geh ich auch manchmal von der Norm ab. Ich mag es wenn es mehrere Wege zu einem Ziel gibt.
MFG
Mark Paspirgilis

PS: Um deine Frage zu beantworten, da ich die id's mit komata getrennt hätte würde ich zum Beispiel. nach "1234," suchen. (1234 ist die id des users)
 
Zuletzt bearbeitet:
ich splitte die mir dann immer und pack die in arrays um damit vernünftig arbeiten zu können, hab ja auch gemeint dass das unprofessionell ist aber um ehrlich zu sein empfinde ich das einfacher aber ist ein "Fehler", da es nicht der norm entspricht aber ich bin da ein wenig unkonventioneller xD.

Es ist definitiv nicht einfacher, da Du so ein Feld parsen, selbständig nach möglicher Redundanz überprüfen und beim Einfügen von neuen Terminen bzw Usern erweitern musst. Da dass dann auch PHP-Basis geschieht ist es nicht nur langsamer sondern belastet auch den Prozessor zusätzlich -- was bei kleinen Seiten vielleicht unerheblich bei größeren aber ein Problem werden kann.

Zusätzlich läßt Du über Deine Vorgehensweise auch einfach die Vorteile einer Datenbank an Dir vorbeiziehen, denn das zielgerichtete Selects nach Terminen die bestimmte User haben bzw User die in bestimmten Terminen stecken lassen sich ganz einfach bewerkstelligen ohne jeden Eintrag aus der Datenbank zu lesen und manuell zu vergleichen.

Deswegen wollte ich ihm nur mein beispiel geben falls es ihm hilft aber gleichzeitig davon abraten. Ich mache seit ca. 1,5 jahren MySQL/SQL es ist nicht lange aber ich habe schon ein wenig ehrfahrung, ich probiere nur immer gerne neue Techniken bzw. schlechtere Techniken die in besonderen Fällen die Arbeit erleichtern (man hat mehr arbeit in PHP aber weniger tabellen...), da geh ich auch manchmal von der Norm ab. Ich mag es wenn es mehrere Wege zu einem Ziel gibt.

Ganz ehrlich: Dein Vorschlag ist absolut ungeeignet. Weder beim Erlernen im Umgang mit einer DB noch beim Aufbauen einer solchen. Nach 1,5 Jahren sollte man schon strukturierter mit Datenbanken arbeiten können ohne sie als reinen Datenstack zu benutzen.

PS: Um deine Frage zu beantworten, da ich die id's mit komata getrennt hätte würde ich zum Beispiel. nach "1234," suchen. (1234 ist die id des users)

Dann musste Du aber jeden Termineintrag abfragen und selbständig durchsuchen. Dadurch hast Du nicht nur mehr Programmieraufwand sondern die Komplexität und somit Fehleranfälligkeit Deiner Anwendung steigt unnötig.
 
Ich habe also die Tabelle UserTermine mit den beiden Spalten UserID und Termin ID!

Wenn ich nun beispielsweise für die TerminID 1 3 Personen eintragen will, ergibt das also 3 neue Zeilen: 1 1, 1 2, 1 3 ?

Dass die Struktur einer Datenbank entscheidend ist weiss ich, deshalb wollte ich ja auch vorher hier einige Tipps holen bevor isch blindlings anfange und mir wegen einer ungeeigneten Datenbankstruktur beim Programmieren die Zähne ausbeisse!
 
Zurück