Datenbanknormalisierung

Da ich nicht den andern Thread vollstopfen will hier ein neuer. Wollte den schon früher schreiben, hab ich auch getan, ging jedoch aufgrund eines Fehlers des Forum verloren.
Aaaaalso, folgende Beispielsituation:
Auf jedem Planeten sind Schiffe (ca. 10 Schiffstypen) stationiert. Dazu könnte man also Folgendes machen:

Tabelle Schiffe

ship_id, ship_name etc....
Tabelle Planeten
planet_id, planet_name, koord_x etc......
Tabelle Schiffe auf Planeten
id, planet_id, ship_id, quantity
Ergibt dann sowas:
1, 54645, 1, 200
2, 54645, 2, 100
3, 54645, 3, 50
4, 89536, 1, 100
usw.
Oder aber man macht das ganze "unnormalisiert":

Tabelle Schiffe und Planeten bleibt unverändert

Tabelle Schiffe auf Planeten:
id, planet_id, quantity_ship1, quantity_ship2, quantity_ship3 usw.....
1, 54645, 200, 100, 50
2, 89536, 100
Letzte Version hat IMHO folgenden Vorteil:
Wenn ich alle Schiffe eines Planeten updaten will kann ich das in einer Query tun. Hätte ich eine normalisierte Tabelle bräuchte ich dazu ja über 15 einzelne Querys:

UPDATE `ships_on_planet` SET

`quantity_ship1`=quantity_ship1-$quantity_ship1, `quantity_ship2`=quantity_ship2-$quantity_ship2, `quantity_ship3`=quantity_ship3-$quantity_ship3, `quantity_ship4`=quantity_ship4-$quantity_ship4,
usw.
WHERE `id`=$id
Im Gegensatz zu:

UPDATE `ships_on_planet` SET `quantity`=quantity-$quantity_ship1 WHERE `id`=$id

UPDATE `ships_on_planet` SET `quantity`=quantity-$quantity_ship2 WHERE `id`=$id
UPDATE `ships_on_planet` SET `quantity`=quantity-$quantity_ship3 WHERE `id`=$id
UPDATE `ships_on_planet` SET `quantity`=quantity-$quantity_ship4 WHERE `id`=$id
usw.
Ich sehe denn Sinn von Datenbanknormaliserung schon, beispielsweise ist die nicht normalisierte Version unflexibler, daher man kann nicht "einfach so" einen neuen Schiffstyp anhängen. Doch was Querys angeht denke ich das unnormalisiert einfach schneller ist. Bitte klärt mich auf.

Wie früher auch schon gesagt... Performance kontra Schulbuch.
Entscheide selbst auf was du Wert legst.
Normalisierung ist kein MUSS, sondern ein KANN.
Wenn du für dich klar definieren kannst wieso du auf die Normalisierung verzichtest, dann verzichte drauf.

[x] kopf > schulbuch

Da Du Dich ja mit Deiner Version schon auf eine feste Zahl von Schiff-Typen festlegst, kannst Du Dir die Tabelle "Schiffe" ja auch schon sparen. Warum sollte man etwas in der Datenbank speichern, was eh eine Konstante ist? Und was soll das Feld id in "Schiffe auf Planeten"? Die beiden Fremdschlüssel solten als primary key ausreichen.
Hast Du den die Performanzeunterschied mal gemessen? Was ist, wenn Du tatsächlich mal einen 5. Schiffs-Typen einführen möchtest. Und selbst wenn Du mal 10 Typen hättest, muss das ja nicht bedeuten, dass bei jedem Kampf all die möglichen Typen beteiligt sind und dem entsprechend aktualisert werden müssen.
Faustregel ist: Erstmal muss es anständig funktionieren, und wenn es dann Performance Probleme gibt, wir gemessen, wo das Problem wirklich steckt, dann wird optimiert und dann wird noch mal gemessen und die Ergebnisse verglichen. Ich würde mir Deine Version wirklich nicht ohne große Not antun.

Es muss ja auch nicht immer nur um Perfomance gehen, wenns um die Anwendbarkeit von Designs geht.. auch wenn ich mich in diesen Glaubenskrieg ungern weiter einmische.

Also dass die Tabelle "schiffe" trotz moeglicherweise konstanter Werte sinnvoll ist, finde ich auch, einfach um das Spiel administrativer zu machen und Balancing, etc. komfortabel und zentral regeln zu koennen. Wenn ich den Namen eines Schiffes aendern moechte, dann moechte ich das persoenlich in der Datenbank tun und nicht in moeglicherweise diversen Header files / Libs.
Ich stimme ebenfalls zu, dass das ID Feld in der many to many Tabelle überflüssig ist.
Zum eigentlichen Problem.. hmmm das habe ich einfacher, weil bei mir jedes Schiff selbst eine Eintität ist und daher auch immer einen eigenen Zustand hat, der beschrieben werden muss und nicht nur eine Zahl in einer Tabelle ist.
Letztendlich denke ich, dass es relativ egal ist, aber man eben wie schon erwähnt Dinge wie Erweiterbarkeit berücksichtigen sollte.
Zudem ist mir persönlich aufgefallen, dass man sich oft viel zu viele Gedanken über Performance von dergleichen Kleinigkeiten macht, die nicht wirklich relevant sind und verglichen mit anderen Codeabschnitten absolut marginale Auswirkungen haben.