Hallo dedlfix,

zunächstmal danke für deine ausführliche und präzise Antwort.
Das ist genau der "Denkanstoß" nach dem ich gesucht habe.

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.

Bei dem Wort "Enum" hat es klick gemacht. Wie gesagt ich bin in dieser Thematik ohne wirkliche Praxis und habe eine Menge wieder vergessen. Du hast natürlich völlig Recht. Enum ist hier die richtige Lösung um das Sicherstellen der richtigen Werte zu gewährleisten.

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).

Hier sprach ich davon, dass die Tabelle "sehr groß" werden könnte. Das ist natürlich relativ. Das das DBMS diese Größen ohne Mühe behandeln kann ist mir klar. Ich hatte diesen Lösungsansatz auch schon bedacht, nur wollte ich zunächst nach Alternativen suchen.
Mein Gedankengang war hier der folgende:
Die Kosten gehören natürlich direkt zu einer Karte, was dafür sprechen würde, diese direkt in die Tabelle "Karte" zu integrieren. Die wirklichen Ausspielkosten sind allerdings eine Kombination aus den drei genannten Rohstoffen, daher einzeln nur bedingt von der KartenID abhängig.
Aber auch hier erkenne ich deinen Einwand, dass man ggf. mehr Joins braucht um sich die Datensätze so zusammen zu stellen, wie man sie benötigt. Hier werde ich wohl nochmal in mich gehen und mir auch darüber Gedanken machen, wie ich Backendseitig die Logik aufbauen werden. (Es wird noch weitere Ausspielkosten geben, aber diese werden ganz anders behandelt)

Ich muss gestehen, dass ich bei deiner Hilfe bezüglich meiner Frage der "Kartenarten" noch nicht sicher bin, ob ich da alles richtig verstanden habe.
Ist es richtig, das du mir zusammengefasst rätst, sämtliche Kartentypen wie z.B. Gebäude, Spontaner Angriff, Menschen etc. in einem ENUM zusammen zu fassen und zusätzlich die vielen Attribute wie z.B. Angriffskraft, Lebenspunkte etc. in die Tabelle "Karte" zu integrieren?

Das wäre sicherlich so umzusetzen und meiner Meinung nach auch die einfachste Form, nur bekomme ich dann ggf. bei der Bearbeitung der Daten Probleme. Wenn ich z.B. eine Karte ausspielen möchte, die alle "Kreaturen" betrifft, dann muss ja irgendwo eine Information vermerkt sein, die mir sagt, dass ein Mensch, ein Troll und ein Gnom Kreaturen sind, allerdings ein Gebäude nicht. In einem Enum in der Datenbank wäre ja der Kartentyp Mensch gleichwertig wie ein Gebäude, obwohl es ja eigentlich nur eine Unterkategorie von "Kreaturen" sind.

Vielleicht liefert mir das Datenbanksystem diese Unterscheidung auch nicht und ich muss das alles mit Interfaces im Sourcecode bearbeiten, aber ich bin ja noch in der Planungsphase und versuche mir möglist viele Scherereien bei der Umsetzung zu sparen! ;)

Sollte ich irgendetwas nicht richtig zitiert oder verstanden haben, bitte ich um Nachsicht. Ich bin nunmal ein DB Anfänger! ;)

Gruß,
Time