Ein paar Fragen...
-
Hallo Leute,
Ich habe in der Schule die Aufgabe bekommen, eine Datenbank fuer einen von mir ausgewaehlten Zweck zu erstellen. Dafuer soll ein logisches, sowie ein relationales Datenmodell erstellt werden.
Ich habe mir ausgesucht, eine Spielergebnisdatenbank fuer das Spiel "League of Legends" zu machen. Fuer jedes Spielergebnis erzeugt man einen Eintrag in der Tabelle "game_result", wobei diese je Spieler einen Verweis auf das Ergebnis das Spielers hat, welches in einer extra-Tabelle "player_result" gespeichert wird.
Mein Lehrer meinte jetzt, dass meine Modellierung dieser Beziehung schlecht ist, man solle stattdessen eine 1:N-Beziehung verwenden. Ich habe keine Ahnung, wie er das meint, er war nicht in der Lage, mir das verstaendlich zu erklaeren.
Hier sind meine Datenmodelle:
Logisch: http://img4.fotos-hochladen.net/uploads/screenshot2011c03m6lvj8.png
Relational: http://img4.fotos-hochladen.net/uploads/screenshot2010su84maqht.pngVielleicht kann mir ja jemand erklaeren, wie man das besser machen koennte.
Gruesse,
Der Kellerautomat
-
ich sehe viele _1, _2, etc, -Spalten. Das kann man sicher noch weiter aufschlüsseln (team, game_team, team_player, game_ban, etc.).
-
In jedem Team gibt es ja auch 5 Spieler, wobei jeder bis zu 6 Items kaufen kann. Was meinst du mit 'aufschluesseln'?
-
deartige spezifischen Regeln bildet man nicht im Datenbankschema ab. An Ende willst du die Teamgröße verändern, oder auch Matches mit 3 vs. 3 erlauben, etc.
-
Vielleicht koennte man mir ja mal konkret sagen, wie man das abbildet, anstatt mir zu sagen, dass man es so nicht tut?! Eine fixe Teamgroesse halte ich fuer durchaus OK. Die Attribute sind uebrigens nullable...
-
Niemand?
-
Kellerautomat schrieb:
Eine fixe Teamgroesse halte ich fuer durchaus OK.
Was ist, wenn es später 10vs10-Spiele geben soll? Mach es, wie dein Lehrer und zwutz dir empfehlen: Normalisiere. Dann gibt es eine Tabelle Ergenis mit einem Verweis auf Spiel und Spieler und einer Spalte für Punkte oder was auch immer du eintragen willst. Wenn du anfängst, Spalten durchzunummerieren (sagen wir mal mehr als zwei), ist das oft ein starker Indikator dafür, dass du eine neue Tabelle einführen solltest.
-
Michael E. schrieb:
Was ist, wenn es später 10vs10-Spiele geben soll?
Ich weiss (aus Quellen der Spielefirma), dass das nie der Fall sein wird. Und selbst wenn, dann fuege ich eben nochmal 10 Spalten hinzu... Wo liegt das Problem?
Michael E. schrieb:
Mach es, wie dein Lehrer und zwutz dir empfehlen: Normalisiere. Dann gibt es eine Tabelle Ergenis mit einem Verweis auf Spiel und Spieler und einer Spalte für Punkte oder was auch immer du eintragen willst.
Mit dem Begriff "normalisieren" fange ich nichts an...
Und ich hab doch schon eine Ergebnis-Tabelle, sogar zwei! Was wozu brauch ich denn die dritte? Was fuer Ergebisse stehen dann da drinnen?Michael E. schrieb:
Wenn du anfängst, Spalten durchzunummerieren (sagen wir mal mehr als zwei), ist das oft ein starker Indikator dafür, dass du eine neue Tabelle einführen solltest.
Ich hab doch eh' schon so viele Tabellen, das kennt man sich ja bald nicht mehr aus :|
-
Siehe http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
Insbesondere die Abschnitte von 1. bis 3. Normalform solltest du lesen.
-
Du kannst aber nicht sinnvoll 10 weitere Spalten hinzufügen. Bzw das ist unpraktisch. Hast du dann ein 4v4 oder 5v5 Spiel sind einfach etliche Spalten leer.
Besser wäre eine 1:n verknüfpfung. Denn 1 Playerresult gehört zu GENAU einem Spiel, und ein spiel kann MEHRERE Playerresults haben. Dadurch wird das Datenbankschema um einiges schlanker.
Den Tipp mit der Normalisierung solltest du dir zu herzen nehmen. Am besten gehst du mal zu deinem Lehrer und sagst ihm, er soll euch das erklären. Das ist elementar wichtig, wenn man vernünftige Datenbankanwendungen erstellt.
Und wie nman schon sagte: Die ersten 3 Normalformen reichen erstmal. Alles weitere sind mehr oder weniger spezialfälle, die nicht so dringend sind. mit den ersten 3 Formen erreicht man schon eine ganze menge
-
typo schrieb:
Und wie nman schon sagte: Die ersten 3 Normalformen reichen erstmal. Alles weitere sind mehr oder weniger spezialfälle, die nicht so dringend sind. mit den ersten 3 Formen erreicht man schon eine ganze menge
stimmt, eine schlechte performance gibts dann gratis
-
oO schrieb:
stimmt, eine schlechte performance gibts dann gratis
Als ob a) du wirklich Ahnung von DB-Performance haettest und b) in diesem Fall hier Denormalisierung tatsaechlich sinnvoll oder gar noetig waere.
edit: Oder sollte das ein Kommentar zu "besonders die ersten 3 Normalformen ansehen" sein? Auch dann verstehe ich nicht, worauf du hier hinauswillst.
-
nman schrieb:
Als ob a) du wirklich Ahnung von DB-Performance haettest
solche kommentare machen dich iwie unsympathisch - aber gut, dafür kann man sich eh nichts kaufen
-
oO schrieb:
solche kommentare machen dich iwie unsympathisch - aber gut, dafür kann man sich eh nichts kaufen
Du erzählst hier generell viel Blödsinn und allerspätestens wenn du dann in Threads Anfänger verunsicherst ohne sonst irgendwas beizutragen, sind mir meine Sympathiewerte bei dir ziemlich egal.
Hast du dem OP irgendwas zu sagen? Dann sag es. Auf konkrete technische Kritik kann man eingehen. Posts "stimmt, eine schlechte performance gibts dann gratis
" sind aber einfach völlig wertlos, weil niemand eine Ahnung hat, worauf du hinausmöchtest oder ob du einfach aus der Deckung heraus trollst wie so oft.
-
ich bin beeindruckt! du hast neue tasten auf deiner tastatur gefunden... heißt das du bist endlich aufgestiegen
-
oO schrieb:
typo schrieb:
Und wie nman schon sagte: Die ersten 3 Normalformen reichen erstmal. Alles weitere sind mehr oder weniger spezialfälle, die nicht so dringend sind. mit den ersten 3 Formen erreicht man schon eine ganze menge
stimmt, eine schlechte performance gibts dann gratis
Ich verstehe Deinen Kommentar nicht. Wann bekommt man eine schlechte Performance? Meinst Du, wenn die Datenbank normalisiert ist, dann bekommt man sie? Ich meine das nicht irgendwie ironisch sondern würde einfach mal verstehen, was Du meinst.
