 |
|  |
Ich brauche Hilfe für einen Logischen Datenbankaufbau
Seit einem Monat befasse ich mich nun mit PHP und MySQL. Das ist nicht sehr viel, aber trotzdem möchte ich gerne versuchen ein Projekt zu realisieren.
Dabei geht es darum eine Resultateseite für meinen Leichtathletikverein zu machen. Später sollen die Besucher dann die Resultater unserer Athleten nach Event, Name, Bestenliste nach Jahr und Bestenliste von jeher, ansehen können.
Momentan sitze ich hier bei 28°C steigend, hoffe dass die Hornisse, die gerade in mein Zimmer gekommen ist mich in Ruhe lässt, und denke über die Zusammenstellung der Datenbank nach. Ich habe hier mal eine kleine Liste gemacht, so wie mir das Ganze am einfachsten erscheint. Da ich, wie gesagt, aber noch kein Profi bin, nehme ich mal an, es gibt einige Fehler in meiner Logik.
Ich hoffe ihr könnt mir weiterhelfen. Ich bedanke mich jetzt schon mal für euere Antworten. Hier mal meine Liste:
Um alles für mich übersichtlicher zu machen habe ich alles hier zusammengefasst:
http://www.faramelli.com/php/
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »faragerri« (12. Juli 2006, 11:57)
RE: Ich brauche Hilfe für einen Logischen Datenbankaufbau
Wie hast du dir denn gedacht die 3 Tabellen zu verknüpfen?
Ich seh da nirgendwo Verknüpfungen zwischen den Tabellen. So, wie's jetzt ist, könnte man ne liste von den Athleten, eine von den events und eine von den Ergebnissen ausgeben.
Weiß leder nicght, wie genau sich die ganzen Sachen aufeinander beziehen. Aber ich denke mal, den Ergebnissen solltest du immer das dazugehörige Event und den Athleten, der es erreicht hat zuordnen, dann sollten all deine Sortierungsvarianten möglich sein.
Wenn du die Sortierung etwas erleichtern möchtest, könntest du noch jeweils die ErgebnisID auch dem jeweiligen Athleten zuordnen, muss aber nicht nbedingt. Würde aber glaub zu weniger Abfrageaufwand führen.
MfG
OnkelJürgen
Auf jede Frage gibt es eine Antwort, man muss nur lange genug danach suchen.
z.B. auf www.netscripter.de :-P
Danke für deine Antwort.
Also ich hatte mir gedacht, man könnte irgendwie die Athleten und Event Tabelle mit der von den Ergebnissen verknüpfungen. Also wenn ich mich nicht irre, der Ergebnistabelle eine AthletenID und eine EventID anfügen, so dass man alles mit einander kombinieren kann.
Ist das nicht der Fall?
Das wäre dann ja so wie oben, habs geändert.
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »faragerri« (12. Juli 2006, 10:14)
Ja, so wäre es prinzipiell möglich.
Der Rest hängt von dem exakten Inhalt, und wie du es ausgeben möchtest, ab.
Wenn du allerdings noch eine Ausgabe anhand des Events machn möchtest, wäre es noch effizienter, auch den Athleten die ID des Events zu geben, sonst müsstest du erst die Ergebnisse auslesen, nach Event-ID ordenen und dann die Eventnamen auslesen und das Ganze ncohmal extra nach dem Alphabet (oder was auch immer) sortieren. 
Das ist erstmal alles, was mir hier spontan dazu einfällt ...
MfG
OnkelJürgen
Auf jede Frage gibt es eine Antwort, man muss nur lange genug danach suchen.
z.B. auf www.netscripter.de :-P
So das hab ich jetzt auch mal editiert. Ich dank dir für deine schnelle Hilfe.
Wie ich in meinem ersten Post geschrieben hatte, möchte ich nachher die Ergebnisse in 4 verschieden Varianten anzeigen können:
Nach Athlet, nach Event, nach Top vom Jahr und nach Top von ever. Natürlich immer der Disziplin nach.
Wie sieht es mit dem Format für die Einträge aus, sind die richtig?
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Enum beim Verein versteh ich nicht ... gibt es denn nur eine sehr begrenzte Anzahl von möglcihen Vereinen?
Bei der Nummer, kA, wie die immer aufgebaut ist, wenn nur Zahlen drin sind, würde auch ein TINYINT reichen, ansonsten VARCHAR.
Saision und ENUM schlißt doch irgendwie künftige Saisions aus, bei Ortschaft auch. Also das würde heißen, es gibt nur eine begranzte ANzahl von Orten in denen die Events stattfinden?
Bei der Zeit kannste doch eigentlcih auch einfach DECIMAL nehmen. Die Nachkommastellen folgen den 10er Regeln und das davor lässt sich doch auch ganz gut sortieren, wenn du das in ganzen Sekunden machst und später beim auslesen einfach noch darauis die Minuten berechnest.
Ansonsten könntest du noch über nen TIMESTAMP gehen und da immer zum Wert 0 die umgerechnete Zeit dazurechnen, aber kA, ob das so günstig ist.
Was Wind ist, weiß cih auhc nicht, also was da genau für Werte zu erwarten sind.
MfG
OnkelJürgen
Auf jede Frage gibt es eine Antwort, man muss nur lange genug danach suchen.
z.B. auf www.netscripter.de :-P
Also Verein und Nummer habe ich mal nach Event verschoben, da diese beide wechseln können.
Die Anzahl an Vereinen soll in einer ersten Phase nicht mehr als 10 betragen, deshalb das enum.
Die Nummer sind normalerweise nur Zahlen, bis zu 6 Stellen.
Die Ortschaften sollen für den Anfang auch erstmal auf 8 begrenzt sein, sonst woh auch varchar?
Die nächste Saison kann ja dann jedes Jahr neu als Option in die Datenbank eingefügt werden oder nicht?
Also bei der Zeit nehme ich dann Decimal und rechne daraus die Minuten um. In der Datenbank wäre dann eine 1:45.69 einfach 105,69?
Bei Wind sind werte von minimal -10 bis + 10 zu erwarten. Mehr sicherlich nicht.
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »faragerri« (12. Juli 2006, 11:09)
Klar kann man zusätzliche Enums hinzufügen, aber ich finde es nicht so günstig dann nachträglich immer wieder was an der DB-Struktur zu ändern.
Ja, bei Orten würde ja auch VARCHAR gehen, muss dann nur eben immer gleich geschrieben werden, aber wenn das eh sio begrenzt ist, würde es mit nem ENUM natürlich wneiger Speicherplatz belegen.
Ja, und das mit der Zeit ahtte cih mir in etwa so gedacht. PHP hat ja ne Funktion, dass man mit Rest Teilt, dann würdest du einfach die 105,69 durch 60 Teilen udn der Rest wären dann Sekunden und nach dem Komma Milisekunden.
Auf jede Frage gibt es eine Antwort, man muss nur lange genug danach suchen.
z.B. auf www.netscripter.de :-P
Naja, das mit dem gleichschreiben wird sicherlich schiefgehen. Dann mach ich mir lieber die Mühe mit enums. Es gibt ja sicherlich auch ne Möglichkeit diese Mit Php in die Datenbank einzufügen.
Die Formel mit dem Rest wird mir wohl keine Probleme stellen, das steht gut erklärt in einem Handbuch. Ich bedanke mich schon mal bei dir. Ich denke es ist an der Zeit, das ganze etwas übersichtlicher darzustellen. Ich werde das jetzt mal tun und dann diesen Beitrag editieren.
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Gut, okay.
Und ja, das geht auhc mit PHP, genauso wie alle anderen MySQL-Abfragen. Macht ja PHPMyAdmin nicht anders.
Dann wünsch' ich schonmal viel Erfolg mit deinem Projekt. *g*
Auf jede Frage gibt es eine Antwort, man muss nur lange genug danach suchen.
z.B. auf www.netscripter.de :-P
Um alles für mich übersichtlicher zu machen habe ich alles hier zusammengefasst:
http://www.faramelli.com/php/
Hab jetzt noch eine Tabelle hinzugefügt, weil mir das logischer erscheint.
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Da ich's grad lesen:
nicht mehr als 99.999 Positionen notwendig
Naja, reicht da nicht sogar ein TINYINT mit 4 stellen?
Auf jede Frage gibt es eine Antwort, man muss nur lange genug danach suchen.
z.B. auf www.netscripter.de :-P
andere frage: sind die ganzen anto_increments überhaupt richtig? z.B. bei Tabelle 4 hat er ja 2 Fremdschlüssel, die garantiert nicht automatisch befüllt werden sollen
~!__/
..o.o
This is Einkaufswagen.
Copy Einkaufswagen into your signature to help him on his way to world domination.
die sind natürlich falsch, denn phpmyadmin erlaubt nur ein autoincrement per Tabelle
Gute Posts beinhalten auch Argumente, nicht nur Urteile.
Bitte sag mir, dass der Primärschlüssel in der Tabelle results nur result_id ist (wobei ich die id-felder in den tabellen immer nur id nennen würde, sonst werden deine abfragen bandwurmlänge erreichen).
Außerdem brauchst du garkeine result_id, denn ein ergebnis ist durch athleten und event doch wohl eindeutig bestimmt oder? damit wäre (athlete_id,event_id) als primärschlüssel besser geeignet, und die restlichen id's sollten aus redundanzgründen raus da. Ansonsten hast du auf einmal ein Ergebnis für eine Athleten, aber die dem Ergebnis zugeordnete Nationalität ist ne andere als die des Athleten. Sowas führt zu ganz häßlichen Fehlern...
| |
73%
22%
19%
11%
6%
Zitat
nicht mehr als 99.999 Positionen notwendig
