Hallo zusammen,
bisher habe ich immer für alles eigene Tabellen angelegt.
Nun ist mir die Idee gekommen, um das Tabellendesign zu vereinfachen und das Spiel für neue Features flexibler zu halten, die Daten in wenigen Tabellen abzuspeichern.
Beispiel:
Tabellen:
Objekte - Gebäude, Forschungen, Einheiten, Planeten...
Objekttyp - Definition der einzelnen Objekttypen (z.B. Gebäude, Einheit, Forschung)
Objekterweiterung - Eigenschaften der Objekte, je nach Objekttyp können hier verschiedene Eigenschaften eingetragen sein: z.b. Einheiten haben Kampfkraft / Verteidigungswert, Gebäude haben Rohstoffkosten, Rohstoffproduktion usw.
Somit wären die Daten in ein einheitliches Format gepresst und eventuelle Erweiterungen meiner Meinung nach einfacher durchführbar, als wenn ich jeweils eine Tabelle: Gebaeude, Einheiten, Forschungen usw. habe.
Was meint ihr dazu? Halten ihr den Weg für vorteilhaft / nachteilig?
mfg
Sammy
Tabellendesign
gepostet vor 18 Jahre, 11 Monate von sammy
gepostet vor 18 Jahre, 11 Monate von Kampfhoernchen
Vorteil: Flexibel
Nachteil: EXTREM UNPERFORMANT
Nachteil: EXTREM UNPERFORMANT
gepostet vor 18 Jahre, 11 Monate von Chojin
hm... wie willst du z.b. eine liste aller gebäude die der spieler hat + die er bauen kann mit den üblichen eigenschaften (bauzeit, kosten, produktion) in eine datenbankausgabe bringen?
ich kenn das problem von meinem spiel selbst. dort gibt es:
Angriffe -> Kampfgruppen -> Einheiten(Anzahl) -> Einheiten(Kampfwerte)
wären theoretisch gleich ein paar (left) join's und die sind bekanntlich schon allein genommen nicht sehr performant (obendrein in sehr großen tabellen).
Vieleicht hat ja jemand eine schlaue lösung parat.
reg4rds
chojin
ich kenn das problem von meinem spiel selbst. dort gibt es:
Angriffe -> Kampfgruppen -> Einheiten(Anzahl) -> Einheiten(Kampfwerte)
wären theoretisch gleich ein paar (left) join's und die sind bekanntlich schon allein genommen nicht sehr performant (obendrein in sehr großen tabellen).
Vieleicht hat ja jemand eine schlaue lösung parat.
reg4rds
chojin
gepostet vor 18 Jahre, 11 Monate von Fabi^
warum nicht die gebäudetypen, beschreibung, techtree... usw in array packen oder halt einzelne vars die includet werden wenn man sie braucht?
= flexibel und ohne db
also z.b. gebarray.php
und dann:
$gebarray= array(
"geb1",
"geb2",
... );
kann man auch leicht umändern
= flexibel und ohne db
also z.b. gebarray.php
und dann:
$gebarray= array(
"geb1",
"geb2",
... );
kann man auch leicht umändern
gepostet vor 18 Jahre, 11 Monate von sammy
Original von Kampfhoernchen
Vorteil: Flexibel
Nachteil: EXTREM UNPERFORMANT
das muss ja nicht zwangsläufig so sein.
Klar, etwas unperformanter als in einer Tabelle wird es auf jedenfall sein.
Wenn man jedoch vernünftige Indizes setzt, denke ich das es trotzdem recht flott geht.
gepostet vor 18 Jahre, 11 Monate von TheUndeadable
Ich persönlich hatte eine Zeitlang eine Mischung aus einem 'echten' und dem generischen Tabellendesign gehabt.
Es gab immer ein Tabellenpaar:
'%name%_item' besaß alle Spalten, die häufig benötigt werden
'%name%_property' konnte alle weiteren Werte speichern.
Angesteuert wurde es über eine Klasse:
$szItem = $oTable->CreateItem();
$oTable->SetProperty ( $szItem, 'name', 'Martin' ); <- kam automatisch in die _item Klasse, da ich vorher für die Tabelle die Spalte 'name' als häufig genutzt gekennzeichnet hatte
$oTable->SetProperty ( $szItem, 'völlig unwichtig', 'fdasjk' ); <- kam in property
Insgesamt war ich sehr zufrieden und werde es in zukünftigen Projekten ähnlich handhaben...
http://nopaste.php-q.net/173769 <- Die Klasse
Es gab immer ein Tabellenpaar:
'%name%_item' besaß alle Spalten, die häufig benötigt werden
'%name%_property' konnte alle weiteren Werte speichern.
Angesteuert wurde es über eine Klasse:
$szItem = $oTable->CreateItem();
$oTable->SetProperty ( $szItem, 'name', 'Martin' ); <- kam automatisch in die _item Klasse, da ich vorher für die Tabelle die Spalte 'name' als häufig genutzt gekennzeichnet hatte
$oTable->SetProperty ( $szItem, 'völlig unwichtig', 'fdasjk' ); <- kam in property
Insgesamt war ich sehr zufrieden und werde es in zukünftigen Projekten ähnlich handhaben...
http://nopaste.php-q.net/173769 <- Die Klasse
gepostet vor 18 Jahre, 11 Monate von sammy
Ich denke ich werde das mal versuchen, notfalls steige ich dann hinterher wieder um.
Wenn ich überwiegend mit Views arbeite, sollte das auch im Nachhinein nicht alles umwerfen.
Wenn ich überwiegend mit Views arbeite, sollte das auch im Nachhinein nicht alles umwerfen.
gepostet vor 18 Jahre, 11 Monate von Klaus
ich benutze für feste Werte auch die Arrays. Die werden dann, wenn benötigt, included. Das parsen dauert zwar, aber mit pre-compiler geht das wieder ratzfatz.
Dazu habe ich noch ein klassisches Tabellendesign mit großen Cache-Anteil, d.h. die Daten kommen in mehreren Tabellen doppelt vor, damit man nicht joinen muss. Versuchst du das mit deinem System zu umgehen?
Dazu habe ich noch ein klassisches Tabellendesign mit großen Cache-Anteil, d.h. die Daten kommen in mehreren Tabellen doppelt vor, damit man nicht joinen muss. Versuchst du das mit deinem System zu umgehen?
gepostet vor 18 Jahre, 11 Monate von Fornax
In einem Verzeichnis habe ich die "Grunddatei". Sie included in versch. Unterordnern weitere Dateien (z.B. die, die die Einheiten included). Diese stellt die Namen der Einheiten. Aufgrund der Namen included sie in weiteren Unerverzeichnissen pro Einheit eine Datei, in der die Daten stehen (Kosten, Dauer, usw.)
gepostet vor 18 Jahre, 11 Monate von sammy
Ich habe mir das ganze etwa so gedacht wie TheUndeadable geschrieben hat.
In einer Tabelle stehen erstmal eine gewisse Anzahl Grunddaten (Name usw.)
In einer Eigenschaften Tabelle stehen dann zu jedem Objekt x-Eigenschaften, je nachdem was für ein Objekttyp es ist.
Auf das ganze greife ich dann per Views zu, die mir die Daten dann direkt auswertet. Somit plage ich mich dann nicht mit Joins im PHP Source herum.
Es gibt dann z.B. die View V_GEBAEUDE, die mir dann die Gebäude mit ihren Eigenschaften in einer Zeile zurückliefert.
Dateien Includen möchte ich mir eher sparen und das meiste innerhalb der Datenbank machen.
In einer Tabelle stehen erstmal eine gewisse Anzahl Grunddaten (Name usw.)
In einer Eigenschaften Tabelle stehen dann zu jedem Objekt x-Eigenschaften, je nachdem was für ein Objekttyp es ist.
Auf das ganze greife ich dann per Views zu, die mir die Daten dann direkt auswertet. Somit plage ich mich dann nicht mit Joins im PHP Source herum.
Es gibt dann z.B. die View V_GEBAEUDE, die mir dann die Gebäude mit ihren Eigenschaften in einer Zeile zurückliefert.
Dateien Includen möchte ich mir eher sparen und das meiste innerhalb der Datenbank machen.