Tach!

Table Seltenheit

• ID
• Name (Gold, Silber Bronze)

Das sieht mir eher so aus, als ob da ein Enum reicht. Die drei Werte stehen vermutlich fest und es ich gehe davon aus, dass es keine Erweiterungen geben wird. Anderenfalls fügt man im einfachsten Fall den neuen Wert zum Enum hinzu, in schwierigeren Fällen muss man sowieso neu schauen und dann anhand der konkreten Änderungen die weitere Vorgehensweise entscheiden.

Table Karte

• ID
• Name
• Seltenheit
• Kartenart

Table Kosten

• ID
• Gold
• Holz
• Wasser

Wenn es immer diese drei Baustoffe sind und keine weiteren Beziehungen nach anderswo existieren (zum Beispiel zu weiteren Materialen, die man im Spiel braucht. Beispiel Anno, da gibt es neben den Baumaterialen auch Verbrauchsgüter, die aber ansonsten genau gleiche Eigenschaften haben und auch grundlegend so behandelt werden), dann würde ich hier einfach drei Felder in die Tabelle Karte einfügen. Damit spart man sich im weiteren Verlauf ein oder drei Joins (je nachdem, wie man die Abfrage gesteltet).

allerdings fühlt sich das nichts sehr "sauber" an, da dadurch auch die "Karte" Tabelle sehr groß werden könnte.

Definiere "sehr groß"! Gibts es noch deutlich mehr Materialien? Um "groß" musst du dir nicht wirklich Gedanken machen. Die üblicherweise in Kartenspielen enthaltene Datenmenge, langweilt ein DBMS nur.

Das Kartenspiel unterstützt diverse Kartenarten, wie "Taktischer Zug", "Gebäude" und "Kreaturen".

Das könnte ein Enum werden.

Kreaturen gibt es auch noch in unterschiedlichen Ausprägungen, z.B. Trolle, Oger, Menschen etc.

Sieht nach einem weiteren Enum aus.

Taktischer Zug wird einmalig ausgespielt und landet anschließend im Friedhof. Diese Karte hat keine Lebenspunkte und keinen Angriffswert. Ein Gebäude zum Beispiel hat nur Lebenspunkte, aber ebenfalls keinen Angriffswert. Eine Kreatur hat beides.

Das wären dann zwei Spalten, die teilweise null bleiben müssten. Du kannst das in eine weitere Tabelle auslagern, aber auch hier sehe ich wie bei den Baumaterialen ähnliche Notwendigkeiten. Je mehr du auslagerst, desto mehr musst du joinen oder Folgeabfragen stellen. Das was du aufzählst sind mehr oder weniger einfache Eigenschaften, die beim Auslagern nur eine 1:1-Beziehung ergeben. Da sollte man sich schon überlegen, ob der Aufwand die Auslagerung rechtfertigt.

Jetzt stelle ich mir die Frage wie ich sowas vernüftig in ein Datenbankmodell übertragen soll. Ich könnte Werte wie Lebenspunkt oder Angriffpunkte beispielsweise in die "Karte" Tabelle packen, allerdings gibt es eine Vielzahl von karten, die diese Attribute gar nicht besitzt. Das bedeutet, meine Tabelle würden so von null Werten wimmeln.

Das ist nicht wirklich ein Problem. Man muss auch nicht versuchen, krampfhaft eine Trennung einzubauen, die dann anderswo Nachteile mit sich bringt.

Eine andere Möglichkeit wäre der Karte Tabelle Attribute zu geben wie "Einheitentyp", "Gebäudetyp" usw. und dann nur dann zu füllen, wenn die Karte eine Kreatur ist z.B. Das ist allerdings auch nicht sauber, da ja dadurch eine Karte zumindest technisch gesehen ein Gebäude und eine Kreatur gleichzeitig sein könnte.

Das muss dann die Programmlogik anhand der Kartenart unterscheiden. Und das muss sie bei einer Trennung ebenfalls, außerdem auch noch Folgeabfragen stellen. Oder du musst gleich spezialisierte Abfragen mit spezifischen Joins auf bestimmte Kartentypen ausführen, wenn du nach Kartenart getrennt abfragen möchtest.

Ich suche nun nach einem Modell, was mir die Sicherheit der Daten gewährleistet, aber dennoch "smart" und korrekt ist.

Das wird dir die Datenbank auch bei Beziehungen nicht vollständig garantieren können. Wenn zum Beispiel bei den Kosten kein Wasser benötigt wird, ergibt es keinen Unterschied ob das Feld nicht mit null gefüllt oder ein überflüssiger Datensatz in der Tabelle Kosten existiert. Beides wäre ein Fehler. Beides kann das DBMS nicht von sich aus verhindern, ohne dass es um komplexe Prüflogik erweitert wird, deren Umgehung auch noch verhindert werden muss.

(Bitte nur Antworten, die sich mit dem Thema befassen und keine Belehrungen wie z.B. warum (mySQL, Magic etc)

Wenn du sowas schreibst, reizt es doch gerade manche, sich ausgerechnet diesen Aspekt vorzunehmen. Außerdem liegt es dann (auch) an dir, diese Aussagen zu ignorieren und solche Abschweifungen einfach mit Missachtung zu strafen.

dedlfix.