Hallo zusammen. Momentan sieht mein Datenbank Layout folgendermaßen aus,
meine Tabelle Gebäude sieht zirka so aus,
Galaxie,System,Planet,GebäudeId,Gebäudelvl
Nun habe ich damals das halt so gewählt, obwohl ich mittlerweile überlege ob es nicht sinnvoller wäre das ganze so zu gestalten:
Galaxie,System,Planet,Gebäude1,Gebäude2,Gebäude3 usw.
Würde mir das Performance Technisch was bringen?
Datenbank Layout für Gebäude
gepostet vor 16 Jahre, 10 Monate von SantaMoU
gepostet vor 16 Jahre, 10 Monate von SpeedyGTD
das kommt auf das Spiel an, bei mir ist es wie du vorgeschlagen hast umgesetzt und ich sehe das inzwischen als einen großen Fehler an, leider lässt sich dieser nicht so einfach beheben.
wenn du davon ausgehen kannst das die meisten Spieler die meisten Gebäude auf einem Planeten bauen, dann wäre die zweite Möglichkeit sicherlich die beste, wenn du allerdings mehrere Gebäude hast, die nicht jeder Spieler bauen kann, sei es durch irgendwelche Spezialisierungen, Rassen oder sonst etwas, dann wäre die erste Möglichkeit vermutlich die bessere.
wenn du davon ausgehen kannst das die meisten Spieler die meisten Gebäude auf einem Planeten bauen, dann wäre die zweite Möglichkeit sicherlich die beste, wenn du allerdings mehrere Gebäude hast, die nicht jeder Spieler bauen kann, sei es durch irgendwelche Spezialisierungen, Rassen oder sonst etwas, dann wäre die erste Möglichkeit vermutlich die bessere.
gepostet vor 16 Jahre, 10 Monate von Nightflyer
de.wikipedia.org/wiki/Normalisierung_(Datenbank)
Je normalisierter eine Datenbank ist, daher je kleiner die Bruchstücke in der DB sind, desto leichter lässt sich was ändern. Eine normalisierung zu ignorieren macht performancetechnisch nur bei Daten sinn welche nicht zwingend Up-to-date sein müssen.
Beispiel:
User-Tabelle: user_id, username, pw, etc.
Galaxie-Tabelle: galaxie_id, user_owner_id, username, etc.
Hier habe ich den Usernamen auch in die Galaxie-Tabelle genommen obwohl ich ihn per LEFT JOIN aus der User-Tabelle über t1.`user_owner_id`=t2.`user_id` holen könnte. Da es aber reicht wenn der Username aller Objekte ein paar mal pro Tag aktualisert wird kann ich mir das LEFT JOIN sparen.
Je normalisierter eine Datenbank ist, daher je kleiner die Bruchstücke in der DB sind, desto leichter lässt sich was ändern. Eine normalisierung zu ignorieren macht performancetechnisch nur bei Daten sinn welche nicht zwingend Up-to-date sein müssen.
Beispiel:
User-Tabelle: user_id, username, pw, etc.
Galaxie-Tabelle: galaxie_id, user_owner_id, username, etc.
Hier habe ich den Usernamen auch in die Galaxie-Tabelle genommen obwohl ich ihn per LEFT JOIN aus der User-Tabelle über t1.`user_owner_id`=t2.`user_id` holen könnte. Da es aber reicht wenn der Username aller Objekte ein paar mal pro Tag aktualisert wird kann ich mir das LEFT JOIN sparen.
gepostet vor 16 Jahre, 10 Monate von raufaser
Ich denke es ist allgemein besser, die Erweiterbarkeit im Auge zu behalten. Zudem der Performance Unterschied nicht so groß sein wird. Ein modernes Datenbanksystem sollte einen Join über ein paar Tabellen schließlich schon performant hinbekommen.
Von daher: Deine erste Idee war in meinen Augen richtig und die bessere - ist einfach sauberer.
(Wobei die 2. Variante natürlich auch funktioniert, aber man jedes mal bei Erweiterungen auch die Tabelle verändern muss...)
Von daher: Deine erste Idee war in meinen Augen richtig und die bessere - ist einfach sauberer.
(Wobei die 2. Variante natürlich auch funktioniert, aber man jedes mal bei Erweiterungen auch die Tabelle verändern muss...)
gepostet vor 16 Jahre, 10 Monate von Amun Ra
Ich will hier jetzt kein Flamewar starten !!!
But sometimes normalizing data is for sissies
www.kottke.org/04/10/normalized-data
www.infoq.com/news/2007/08/denormalization
...
Es ist die Kunst zu wissen, wann Normalisierung der Daten Sinn macht
und wann nicht !
But sometimes normalizing data is for sissies
www.kottke.org/04/10/normalized-data
www.infoq.com/news/2007/08/denormalization
...
Es ist die Kunst zu wissen, wann Normalisierung der Daten Sinn macht
und wann nicht !
gepostet vor 16 Jahre, 10 Monate von Fatal_Error
Original von Amun Ra
Es ist die Kunst zu wissen, wann Normalisierung der Daten Sinn macht
und wann nicht !
jap und wie es bei kottke in den kommentaren richtig steht, bin ich auch der Meinung, dass es meistens am besten ist seine db erstmal normalisiert aufzubauen und wenn man merkt, dass eine denormalisierung angebracht ist wegen performance-optimierung von suchanfragen o.ä. dann kann man immer noch diese teile/tabellen wieder denormalisieren und die logik ins programm auslagern...
das kunst auch immer ansichts- und geschmackssache ist, brauch ich hier jetzt wohl nicht mehr zu erwähnen
gepostet vor 16 Jahre, 10 Monate von TheUndeadable
Ich persönlich favorisiere für jeden Gebäudetyp eine eigene Zeile.
Also: buildingid, buildingtype, playerid, level
Das Problem stellt sich, wenn man das Spiel erweitern möchte. Ohne diese Normalisierung darf man die Tabelle und den Code modifizieren, das gleiche bei Umbenennungen.
Auch wenn du jedem Gebäude plötzlich eine Eigenschaft geben möchtest (Gebäude aktiv, Gebäude brennt, etc) fängt dann der Spaß mit vielen neuen Spalten an.
@Amun Ra: Wenn du den Artikel sauber gelesen hättest, würdest du sehen, dass der Autor des Artikels ein anderes Problem bespricht.
Also: buildingid, buildingtype, playerid, level
Das Problem stellt sich, wenn man das Spiel erweitern möchte. Ohne diese Normalisierung darf man die Tabelle und den Code modifizieren, das gleiche bei Umbenennungen.
Auch wenn du jedem Gebäude plötzlich eine Eigenschaft geben möchtest (Gebäude aktiv, Gebäude brennt, etc) fängt dann der Spaß mit vielen neuen Spalten an.
@Amun Ra: Wenn du den Artikel sauber gelesen hättest, würdest du sehen, dass der Autor des Artikels ein anderes Problem bespricht.
gepostet vor 16 Jahre, 10 Monate von Agmemon
Also ich finde den ersten Ansatz auch besser, als den zweiten Ansatz. Wobei man ihn, wenn ich es inhaltlich richtig verstehe, noch optimieren könnte. Dies ergibt sich daraus, wenn man, wie man es auch machen sollte, in Entitäten denkt.
Du hast eine Entität Planet und eine Entität Gebäude. Diese stehen in Relation zueinander. Dabei verfügt die Relation über Zusatzinformationen. Übertragen auf Tabellen heißt das, eine Tabelle für die Planeten, eine für die Gebäude und eine Koppeltabelle für die Relation mit den Zusatzinformationen.
Was die Normalisierung betrifft, muss ich Amun Ra allerdings widersprechen. Die Kunst ist zu wissen, wann der positive Effekt einer Denormalisierung den Nachteilen überwiegt. Und das ist bei den ersten drei Normalformen so gut wie nie der Fall. Bei der 4. und 5. NF ist das vermutlich anders, weshalb man sie in der Praxis auch so selten sieht.
Du hast eine Entität Planet und eine Entität Gebäude. Diese stehen in Relation zueinander. Dabei verfügt die Relation über Zusatzinformationen. Übertragen auf Tabellen heißt das, eine Tabelle für die Planeten, eine für die Gebäude und eine Koppeltabelle für die Relation mit den Zusatzinformationen.
Was die Normalisierung betrifft, muss ich Amun Ra allerdings widersprechen. Die Kunst ist zu wissen, wann der positive Effekt einer Denormalisierung den Nachteilen überwiegt. Und das ist bei den ersten drei Normalformen so gut wie nie der Fall. Bei der 4. und 5. NF ist das vermutlich anders, weshalb man sie in der Praxis auch so selten sieht.
gepostet vor 16 Jahre, 10 Monate von Amun Ra
Okay war vielleicht etwas zu direkt ausgedrückt.
Aber ich habe bei mir einige Beispiele,
bei denen die Vorteile überwiegen.
Aber ich habe bei mir einige Beispiele,
bei denen die Vorteile überwiegen.
gepostet vor 16 Jahre, 10 Monate von DrakeL
Original von SantaMoU
Hallo zusammen. Momentan sieht mein Datenbank Layout folgendermaßen aus,
meine Tabelle Gebäude sieht zirka so aus,
Galaxie,System,Planet,GebäudeId,Gebäudelvl
Ich würde jedem Planeten eine eindeutige ID geben, vor allem für die Relationen zwischen den Tabellen wichtig:
Tabelle Planet: planetid, galaxie, system, planet
Tabelle Gebäude: planetid, gebaeudeid, gebaeudelvl
Ich kenne das von meiner Firma her, da ist die Kundennummer Schlüssel fast jeder Tabelle, nun stellt sich einer den Aufwand vor wenn ein Kunde mal eine andere Kundennummer bekommt, was recht häufig vorkommt. Also in deinem Fall, wenn du mal einen Planeten "umziehen" lassen willst oder ähnliches geht das so wunderbar. Irgendeine Regel, kann sein dass es eine der Normalformen ist, sagt auch aus, dass keine Attribute als Schlüssel genommen werden sollen. Vor allem hast dann nur eine Spalte als Schlüssel zu einem Planeten und nicht immer drei.
Original von SantaMoU
Nun habe ich damals das halt so gewählt, obwohl ich mittlerweile überlege ob es nicht sinnvoller wäre das ganze so zu gestalten:
Galaxie,System,Planet,Gebäude1,Gebäude2,Gebäude3 usw.
Würde mir das Performance Technisch was bringen?
Performance wäre hier eher ein Nebeneffekt, den es zu berücksichtigen gibt. Du solltest aber vor allem die Hauptunterschiede bedenken. Wie vorher schon jemand gesagt hat, wenn es verschiedene Rassen mit komplett andren Gebäuden gibt (nicht nur andere Namen, sondern auch andere Funktionen und vor allem in verschiedenen Anzahlen) oder es öfters vorkommt, dass neue Gebäude hinzu kommen, dann solltest eher den ersten Ansatz wählen. Es ist unkomplizierter bei einem neuen Gebäude eine Zeile mehr zu haben in der DB als immer eine neue Spalte hinzuzufügen.
Andererseits wenn die Stufen aller Gebäude haben willst brauchst so wesentlich mehr Zeilen zum Auslesen. Ich habe z.B. den zweiten Ansatz gewählt, einfach weil es bei mir nicht vorkommt, dass Gebäude in einer laufenden Runde hinzugefügt werden (also an der DB Struktur muss somit auch nichts geändert werden) und nach einer Runde wird die DB Struktur bei mir immer neu erstellt, von daher ist das kein Problem für mich.
Du musst einfach für dich entscheiden was in deinem Falle besser geeignet ist. Beides hat Vor- und Nachteile. Kurz das Erste ist flexibler, aber "aufwendiger". Das Zweite ist relativ statisch aber dafür leichter zu handhaben und etwas schneller, vor allem wenn man alle Gebäudestufen braucht.
gepostet vor 16 Jahre, 10 Monate von knalli
Mal ne ganz blöde Anmerkung: Wenn Kundennummer in der Datenbank als Key verwendet wird, wie kann man den Key bitte schön die ganze Zeit verändern?
Einmal angesehen davon, das ich (auch als Kunde!) nicht verstehen kann, wieso ich dauernd neue Kundennummern bekommen sollte, hat da doch jemand das Datenbankdesign nicht verstanden. Entweder als keine Änderungen am Schlüssel, oder zwischen Schlüssel und Kundennummer unterscheiden (neue Spalte). Kundennummer muss ja kein Primary Key sein, es ist "nur" der Regelfall. Wird dann halt ein Künstlicher Schlüssel.
Das kann man ja durchaus auch auf ein Browsergame beziehen, wenn Planten vielleicht eine Nummer haben (ähnlich wie die kryptischen Bezeichnungen aus Stargate), die aber nicht zwangsläufig die interne ID sind).
Einmal angesehen davon, das ich (auch als Kunde!) nicht verstehen kann, wieso ich dauernd neue Kundennummern bekommen sollte, hat da doch jemand das Datenbankdesign nicht verstanden. Entweder als keine Änderungen am Schlüssel, oder zwischen Schlüssel und Kundennummer unterscheiden (neue Spalte). Kundennummer muss ja kein Primary Key sein, es ist "nur" der Regelfall. Wird dann halt ein Künstlicher Schlüssel.
Das kann man ja durchaus auch auf ein Browsergame beziehen, wenn Planten vielleicht eine Nummer haben (ähnlich wie die kryptischen Bezeichnungen aus Stargate), die aber nicht zwangsläufig die interne ID sind).
gepostet vor 16 Jahre, 10 Monate von DrakeL
Original von knalli
Mal ne ganz blöde Anmerkung: Wenn Kundennummer in der Datenbank als Key verwendet wird, wie kann man den Key bitte schön die ganze Zeit verändern?
Indem man ein Skript schreibt, welche alle Spalten in der Datenbank sucht, in der die Kundennummer verwendet wird und diese dann über Update Statements auf die neue Nummer umstellt (so ganz grob gesagt). Funktioniert super bei uns, keine Frage, aber das Teil muss gepflegt werden und das, obwohl es eigentlich unnötig wäre.
Original von knalli
Einmal angesehen davon, das ich (auch als Kunde!) nicht verstehen kann, wieso ich dauernd neue Kundennummern bekommen sollte, hat da doch jemand das Datenbankdesign nicht verstanden. Entweder als keine Änderungen am Schlüssel, oder zwischen Schlüssel und Kundennummer unterscheiden (neue Spalte). Kundennummer muss ja kein Primary Key sein, es ist "nur" der Regelfall. Wird dann halt ein Künstlicher Schlüssel.
Frag mal deine Bank, wie es passieren kann, dass ein Kunde eine neue Kundennummer bekommt. Ich weiß es leider nicht, bin Entwickler, kein Bankkaufmann.
PS: Will nicht lange rumerzählen warum unser DB Design nicht so gut ist, liegt zum Größtenteil daran, dass das Programm und die Datenbank in den 10 Jahren, seit es die Software gibt, halt immer weiter gewachsen ist und das am Anfang nicht bedacht wurde, dass sowas kommen kann (ändern geht nicht mehr).
gepostet vor 16 Jahre, 10 Monate von None
Original von DrakeL
PS: Will nicht lange rumerzählen warum unser DB Design nicht so gut ist, liegt zum Größtenteil daran, dass das Programm und die Datenbank in den 10 Jahren, seit es die Software gibt, halt immer weiter gewachsen ist und das am Anfang nicht bedacht wurde, dass sowas kommen kann (ändern geht nicht mehr).
Migrieren auf ein neues System. wir hatten in der firma während des betreibsurlaubes auch eine System umstellung im SAP, nämlich aus neue internationale UBK-RM. War zwar jede menge arbeit und überstunden für alle betroffenen, aber jetzt läuft alles.
gepostet vor 16 Jahre, 10 Monate von knalli
Ach, das war eine ironische Frage Mir ist schon klar, dass das jetzt etwas ist, was sich nicht mehr ändern läßt (läuft ja immer so), aber eigentlich ist das wieder so ne Situation, wo man sich nur an den Kopf fassen kann.
Das mit neuen Kontonummern; ja, das kann bei einer Übernahme passieren, aber doch nicht laufend. Nun denn, wenn es mal richtig kracht, kannst du denen ja einen fertigen Bericht mit Verbesserungsvorschlag bieten -.-
Das mit neuen Kontonummern; ja, das kann bei einer Übernahme passieren, aber doch nicht laufend. Nun denn, wenn es mal richtig kracht, kannst du denen ja einen fertigen Bericht mit Verbesserungsvorschlag bieten -.-