Datenbank - Anzahl Tabellen

"Klingt blöd, ist aber so"
Wir sind gerade bei den Arbeiten am Datenbankdesign.
Mich würde interessieren wieviel Tabellen ihr bei eurem Browsergame habt!
Ich schätze das wir auf ca. 40-50 Stück kommen, inklusive Auswertungen.

15 tabellen
wozu zum teufel braucht man 40-50 tabellen????

ich hab so an die 60 denke ich .. ohne forum und den ganzen krams..
PS: 5. NF ftw!

40, auch ohne Forum & co

Ich denke ich werde auch mal auf 40 - 50 kommen. Natürlich auch bei mir ohne Forum usw.

mysql> show tables;
+---------------------------+
| Tables_in_empire          |
+---------------------------+
| accounts_available        |
...
| users                     |
| versions                  |
+---------------------------+
79 rows in set (0.00 sec)

Zur Zeit 21 Tabellen. Aber es kommen noch ein paar dazu.

dann lag ich doch nicht so falsch
ich hoffe nur das es nicht gerade 100 werden

39 Tabellen - die Tabellen für die Karten und Dungeons habe ich abgezogen, da jede Karte, jedes Dungeon eine eigene Tabelle hat und nur 1 Zentraletabelle, um diese zu verwalten.
Ich denke aber es werden auch bei mir noch einige wenige hinzukommen (Gruppen aus Spielern bilden, ...).
Gruß,
Marc

Original von Browser-Games World
15 tabellen
wozu zum teufel braucht man 40-50 tabellen????

Das hängt wohl sehr von der Komplexität des Spiels ab. Ich z.B. habe meine Datenbank relativ flach gehalten und komme trotzdem auf bestimmt 40 - 50 Tabellen, wenn alles fertig ist.
Das sind die Tabellen, die ich zu Zeit habe...

bank
chat
content
dreams
dungeon
fight_players
fractions
gamevalues
guild
guild_players
inventory
ipbans
item
knowledge
knowledge_players
mailbox
map
mapcontent
market
merchant
merchant_items
merch_players
mob
mobspawn
npc
npc_quests
pet
pet_players
player
player_log
pot
quest
questlog
recipe
recipe_players
session
spell
spellbook
tiles
Und: Ich ermutige offiziell auch die anderen Post "SHOW /* ME YOUR */ TABLES;" ... ich fänd's mal interessant. :-)
Gruß,
Marc

Meine Tabellen
48 sind es und ich bin alles, nur nicht am ende der programmierung
dies 2 mal (2 Welten)
und dann noch olympus mit über 60 Tabellen dazu

Bitte entfernt eure Tabellenpostings. Die Anzahl gerne, aber das ist absoluter Unfug.
Sollte einer der hier lesen kann euch was böses wollen, so hat er jetzt einen weiteren Ansatzpunkt für Angriffe.

Original von Browser-Games World
15 tabellen
wozu zum teufel braucht man 40-50 tabellen????

Du willst doch nicht alle relevanten Tabelleninformationen in eine Textspalte serialisieren statt einer vernünftigen Normalenform nachzugehen.

also fuer das Spiel kommen wir mit 22 aus, dazu kann man aber auch die 9 Admintabellen werten, dann sinds eben 31
natuerlich auch alles ohne forum o.ä. und es werden in naher zukuft einige tabellen mehr werden

Also ich mache auch für jede Kleinigkeit eine neue Tabelle.
Also wo man z.B. drauf achten sollte, ist bei Berichten, den eigentlichen Text und den Rest (also Überschrift, Datum, usw.) zu trennen. Machen z.B. auch Boards so.
Damit eben nicht jedesmal diese Textfeld angefragt/durchsucht werden muss, wenn man die Berichtsübersicht aufruft.
ERSTER: :-)
65

Wir liegen derzeit bei ca 40 Tabellen, sind aber noch nicht am Ende der Fahnenstange^^

Bei uns sind es 35, dann kommen noch Forum (30) und Handbuch (35) dazu

handbuch 35?

Original von Sensei
handbuch 35?

Jede Seite eine Tabelle ;-)

Original von Todi42

Original von Sensei
handbuch 35?

Jede Seite eine Tabelle ;-)
Nein, aber ein MediaWiki

Mmmh, bei meinen neuen Projekt lieg ich so an 90! upps^^

Ohne Zubehör wie Forum und Wiki 55 Tabellen.

habt ihr iwie die angewohnheit wirklich alles in mysql zu speichern?
ich speichere lieber in den dateien selber
bzw. baue z.B. alle verschiedenen gebäude indie phpdatei direkt ein

60 Tabellen ohne Forum....

Lol und wenn Du Änderungen an den Gebäuden vornehmen willst bastelst an den Datein rum anstatt dies in den Tabellen zu ändern.
Einige Entwickler hier, haben viele Einträge miteinander verknüpft und wollen nicht wie im Sandkasten mehrere Türmchen bauen und lieber gleich Ordentlich einen Datensatz abändern, der so dann Hand und Fuß hat.

man kann doch die daten in der datei ähnlich der datenbank speichern
spart sogar mysqlabfragen -.-

Original von Browser-Games World
man kann doch die daten in der datei ähnlich der datenbank speichern
spart sogar mysqlabfragen -.-

[ ] Sinn und Zweck einer Datenbank erkannt
[ ] Schicht-Architektur bekannt und genutzt
[ ] wenn 1 und 2: effizientes Datenbankdesign (1, 2, und 3. Normalenform)
Über Normalisierungen (dritte) mag man sich ja noch streiten, aber die Existenz einer Datenbank in einem Browserspiel in Frage zu stellen, das habe ich auch noch nicht erlebt.

82.
@ bgw:
oft sind tabellen dennoch im vorteil. habe aber so dinge wie trefferchancentabellen etc. aus früherer einfachkeit auch in einer art config-datei.
hab ich aber auch nur so gelassen, da ich die mit nix verknüpfen o.ä. muss, immer alle daten auf einmal brauche und auch nur an einer stelle was ändern muss. alles andere ist aber schön verpackt in tabellen..

Original von knalli
Über Normalisierungen (dritte) mag man sich ja noch streiten, aber die Existenz einer Datenbank in einem Browserspiel in Frage zu stellen, das habe ich auch noch nicht erlebt.

Oh, ich könnte mir sehr gut Vorstellen, das man ohne DB einige Problem weniger hätte. Datenbanken sind halt immer noch sehr sehr langsam. Oder anders herum gesagt, "Datenbanken helfen einem Probleme zu lösen, die man ohne Datenbanken nie gehabt hätte." ;-)

Original von open_dimension
Also wo man z.B. drauf achten sollte, ist bei Berichten, den eigentlichen Text und den Rest (also Überschrift, Datum, usw.) zu trennen. Machen z.B. auch Boards so.
Damit eben nicht jedesmal diese Textfeld angefragt/durchsucht werden muss, wenn man die Berichtsübersicht aufruft.

hm.. gibts dafür nicht select und indizes?
habe gerade zwei ca. gleichgroße tabellen von mir verglichen - eine 23 mb groß und ca. 5600 einträge, die andere 400 kb mit 6600 einträgen.
beide haben bei mehreren versuchen (verschiedene werte, um tabellencache zu umgehen) der ausgabe der id immer ~0.0007 sec gebraucht - für 30 reihen, die eingeschränkt wurden auf z.b. einen user... ist das einfach nur glück und ich bin ein idiot oder macht das eh nur beschränkt (und vor allem basierend auf der verwendungsart!) was?

also ich hab 136, mhh das sagt jetzt was aus ? bin ich jetzt aus dem club nur maximal 100 tabellen ausgeschlossen ? ist das der selbe blödsinn wie nur maximal 20 querys pro seitemaufruf ? (da darf ich übrigends auch nicht mitmachen)
mal ernsthaft, ein gutes db design ist bei der weiterentwicklung einfach gold wert. das muss nicht mal in der 3nf sein, solange es perfomant und leicht erweiterbar ist. die anzahl der tabellen sagt dabei gar nix aus.
mal sehn was als nächstes kommt, bestimmt die maximale zeilenanzahl pro table die 23 nicht überschreiten darf oder die gesamtgrösse der db die auf jeden fall unter 42 mb bleiben muss

> also ich hab 136,
Bei deinem Wirtschaftsteil wundert mich das nicht ;-)
Ansonsten wird mein nächstes Browserspiel keine SQL-Datenbank mehr beinhalten, sondern ein eigener Dienst wird sich um die Datenhaltung und Datenmanipulation kümmern.
Und zwar nicht weil mir die Datenbank so langsam ist, sondern weil mir der Objektzugriff zu aufwändig ist. Ich möchte eine native objektorientierte Struktur.

KolonialKampf 1 hatte irgendwas um die 40 Tabellen, wobei ich mich damals öfterst über die Normalisierung geärgert habe. Im Endeffekt hatte ich mehr Ärger dadurch, als ohne.
KolonialKampf 2 hat im Moment um de 15 Tabellen, wobei ich hier auch in einigen Teilen mich wieder von einer Datenbanklösung wegbewege. Im Moment bin ich noch am validieren was wie möglich ist. Selbst bei KK1 hatte ich einige der Daten schon nicht mehr in einer Datenbank abgelegt.
Mal schaun was die Zukunft so bringt

bei meinem waren es zwischen 30-40 Tabellen (gibt es nicht mehr).
aber nur mal zum vergleich Beruflich arbeite ich mit einem ERP System (de.wikipedia.org/wiki/Enterprise_Resource_Planning) da sind zwischen 1500 und 2000 Tabellen drinnen

ich bin ja noch nicht fertig...
aber ich denke auf 40 kommt man locker. Ich selber rechne ehr mit mehr.

Ich habe aktuell 49 Tabellen, bin aber noch nicht komplett durch.
Insbesondere die Log Tabellen werden nochmal mit 25~30 zuschlagen.
Aber was hat denn die Anzahl der Tabellen über das Spiel zu sagen?
Doch eigentlich gar nichts? Wer will den behaupten, viele Tabellen entsprechen
einem tief greifendem Spiel, und Spiele mit wenigen Tabellen sind flach
und öde?
Dem Datenbank Server ist die Anzahl der Tabellen egal, wenn er korrekt
konfiguriert ist.

Ich bin erst bei 20, aber da wird noch einiges hinzukommen. Besonderst aus Performancegründen, wie schon genannt:

Original von open_dimension

[...] Also wo man z.B. drauf achten sollte, ist bei Berichten, den eigentlichen Text und den Rest (also Überschrift, Datum, usw.) zu trennen. Machen z.B. auch Boards so.
Damit eben nicht jedesmal diese Textfeld angefragt/durchsucht werden muss, wenn man die Berichtsübersicht aufruft. [...]

42 Tabellen in der Datenbank pro Server (Spieler, ...)
21 Tabellen in der globalen Datenbank (Wiki, News, ...)

Original von knalli

Original von Browser-Games World
man kann doch die daten in der datei ähnlich der datenbank speichern
spart sogar mysqlabfragen -.-

[ ] Sinn und Zweck einer Datenbank erkannt
[ ] Schicht-Architektur bekannt und genutzt
[ ] wenn 1 und 2: effizientes Datenbankdesign (1, 2, und 3. Normalenform)
Über Normalisierungen (dritte) mag man sich ja noch streiten, aber die Existenz einer Datenbank in einem Browserspiel in Frage zu stellen, das habe ich auch noch nicht erlebt.
tu ich auch nicht
ich bin nur nicht der meinung das man wirklich alles in eine db speichern sollte
bald kommt es noch dazu dass der ganze html code in den datenbanken gespeichert wird
ja sowas habe ich auch schon erlebt

Nein, aber eine Datenbank beinhaltet die Daten deiner Anwendung, nicht von ungefähr kommt ja der Name. HTML ist nur eine Darstellung, die hat eigentlich in der Datenbank nichts zu suchen. Was aber in einer Applikation natürlich schon unter Umständen machen würde, wäre ein sehr dynmisches Templatesystem (evtl XSL, also XML-Typ).. aber ohne sinnvolles Caching wird das eher ein theoretisches Projekt.
Um mal dir zu verdeutlichen, was du machst: Wenn du alle Gebäude in der "HTML/PHP-Datei" schreibst, kannst du keine schnellen Erweiterungen machen. Das mindeste wäre also eine externe Konfiguration (bsp. Array) der Parameterdaten (eines Gebäudes), die man dynamisch auffüllen kann (und hier sind wir an einem Punkt, wo man fragen könnte.. wieso nicht DB?). Wenn aber alle Abfragen, Darstellungen an Ort und Stelle des Gebrauchs sind, ist der Code nicht wirklich erweiterbar, d.h. ein neues Features eines Gebäudes (Tür2) oder ein neues Gebäudetyp (Hochhaus) läßt sich nur mit Editierung von vielen Dateien realisieren.
Aus dem gleichen Grunde verwendet man (auch) Objekte und Klassen. Das macht man doch nicht nur, weil es verpackt und cool ist :S

Bekommt eine Datenbank bei hoher Tabellenanzahl eigentlich Probleme?

Hmmm... ich kann mal als Beispiel aufführen, was man außerhalb einer Datenbank ablegen kann:
* Logs
* Ingame Mails (Archivierung)
* XML Extrakte (kann man ja vorgekaut bei wenig CPU Last erzeugen)
* Ranglisten (1x täglich erzeugt und ab als HTML File o.ä.)
So habe ich es in der Vergangenheit gemacht und bin verdammt gut damit gefahren.
Im beruflichen Umfeld haben wir noch viel mehr Situationen wo eine Datenbank absolut nicht sinnvoll ist. Aber wie so üblich... der Vertrag verhindert das reden

Hehe...also ich kümmer mich gar nicht mehr um Tabellen - macht mein Framework automatisch (Oracle TopLink).
Persistenzframeworks sind was feines :p

Original von RaydenDD
Bekommt eine Datenbank bei hoher Tabellenanzahl eigentlich Probleme?

Nicht wenn der Server ordentlich konfiguriert ist.
Ich persönlich arbeitete aktuell beruflich an einem Projekt, wo wir
aktuell um die 600 Tabellen haben mit einer Gesamtgröße von ~800MB - Tendenz
stark steigend, da noch nicht alle Funktionalitäten eingebaut sind.
Am Ende rechnen wir mit knapp 1000 Tabellen.
Die MySQL Einstellungen stehen aktuell auf 2048 OpenFiles und 1024 MB Ram explizit.
Rennt wie Sau das Ganze auf einem betagten P4 mit Debian Etch drauf.

Also im klassischen Datenbankdesign ist es ja so, dass man pro Entität eine Tabelle hat, bzw. für zwei Entitäten drei Tabellen, bei n:m Relationen. Wenn man sich daran hält, was heute ja wieder modern ist, aufgrund des O/R-Mappings, sagt die Anzahl der Tabellen schon einiges über die Komplexität aus.
Und dieser Ansatz bestimmt eigentlich auch schon selbst, was in die Datenbank gehört. So ergibt sich die Rangliste aus den Entitäten der Anwendung, ist selbst aber keine. Damit hat sie nichts in der Datenbank zu suchen und wird bei Bedarf generiert, oder noch besser, gecached.

Original von knalli
Nein, aber eine Datenbank beinhaltet die Daten deiner Anwendung, nicht von ungefähr kommt ja der Name. HTML ist nur eine Darstellung, die hat eigentlich in der Datenbank nichts zu suchen. Was aber in einer Applikation natürlich schon unter Umständen machen würde, wäre ein sehr dynmisches Templatesystem (evtl XSL, also XML-Typ).. aber ohne sinnvolles Caching wird das eher ein theoretisches Projekt.
Um mal dir zu verdeutlichen, was du machst: Wenn du alle Gebäude in der "HTML/PHP-Datei" schreibst, kannst du keine schnellen Erweiterungen machen. Das mindeste wäre also eine externe Konfiguration (bsp. Array) der Parameterdaten (eines Gebäudes), die man dynamisch auffüllen kann (und hier sind wir an einem Punkt, wo man fragen könnte.. wieso nicht DB?). Wenn aber alle Abfragen, Darstellungen an Ort und Stelle des Gebrauchs sind, ist der Code nicht wirklich erweiterbar, d.h. ein neues Features eines Gebäudes (Tür2) oder ein neues Gebäudetyp (Hochhaus) läßt sich nur mit Editierung von vielen Dateien realisieren.
Aus dem gleichen Grunde verwendet man (auch) Objekte und Klassen. Das macht man doch nicht nur, weil es verpackt und cool ist :S

ich weiss wozu datenbanken sind....
aber die infos die man in der datenbank speichert z.B. für gebäude kann man genauso gut in phpdateien gleich ich variablen schreiben
dadurch spare ich sogar an mysql abfragen.

Ja und wenn du Mods hast, die auch Gebäude machen können dann ist das mit Datenbank wesentlich einfacher.
Einfach ein Insert hin und das Gebäude ist da.
Oder wenn die User Gebäude/Einheitenvorschläge machen können und du(bzw. ein Mod) muss dann einfach nur auf annehmen/ablehnen drücken ist das wesentlich einfacher
PS: Ich hab grad gelesen, dass knalli fast das gleiche geschrieben hat

Für das Thema Usercontent hatte ich bei mir eine XML-Struktur vorgesehen, welche auf der Platte liegt und über einen Parser ausgelesen wird.
In der Datenbank ist bei mir im Moment immer weniger enthalten.
*G*
Ja, ich weiß was ich mache

XML ist aber zum Austausch von Daten zwischen Systemen da.
Gleichwohl nehmen es viele zum Sichern von Daten. Aber XML ist menschlich lesbar und - ohne selbst geschriebenen Parser - super langsam. Bei Konfigurationsdaten ist das natürlich egal - Zeit spielt da eine kleinere Rolle im Allgemeinen.
Aber missbrauche XML nie dazu irgendwelche Daten zu speichern, das ist Pfuiii
Bringt nur Nachteile mit sich und mit ner Datenbank ist es nicht zu vergleichen.
Habe mal einen Bericht von der W3C gelesen, die ärgern sich grün und blau über die Leute die ihr schönes XML als Datenbank missbrauchen

ICh finde ab und an sollte men das W3C durchaus ein wenig ärgern^^

Ok... Datenbank kann theoretisch beliebig groß werden, aber...
* Wer sichert dir die schnell mal zurück bei Problemen?
* Wie und wo speicherst du diese Mengen an Datenbankbackups? Bei uns werden die täglich erstellt und die sind mehrere Hundert GB groß pro Datenbank (Beruflich, nicht BG)
* XML oder ein eigenes Format ist durchaus gängig zum Speichern von Informationen. Hau eine DTD dazu und du wirst auch in 20 Jahren das File noch irgendwo einlesen können.
Ok... ich muß zugeben das ich durch meinen Beruf eine vollständig andere Ausrichtung und ein anderes Verständnis von Datenbanken habe. Wir benutzen die Datenbanken extrem exessiv und gehen oftmals auch über die Limits raus. Das hat zur Folge das irgendwann auch andere Lösungen gewählt werden.
Je nach Bedarf ist ein Textfile um einiges schneller zu verarbeiten als ein Komplexes Query. Lieber dumpe ich die Daten 1x pro Nacht in ein File und habe dann den ganzen Tag Zeit, als die Datenbank mit mehreren Querys mit gleichem Ergebnis dann zuzufahren.
Deshalb... ein BG kann durchaus eine im Vergleich zu Busineslösungen einfache Datenbankstruktur haben.
Aber zu sagen das alles in die Datenbank muß oder XML Pfui ist... *G*
Man man man... was ich schon alles erleben mußte in den letzten Jahren...

Also, erstmal sind es bei uns pro Server 41 Tabellen, plus 3 Tabellen, die für beide Server gelten,...

Original von Nuky

....
habe gerade zwei ca. gleichgroße tabellen von mir verglichen - eine 23 mb groß und ca. 5600 einträge, die andere 400 kb mit 6600 einträgen.
beide haben bei mehreren versuchen (verschiedene werte, um tabellencache zu umgehen) der ausgabe der id immer ~0.0007 sec gebraucht - für 30 reihen, die eingeschränkt wurden auf z.b. einen user... ist das einfach nur glück und ich bin ein idiot oder macht das eh nur beschränkt (und vor allem basierend auf der verwendungsart!) was?
Ich gehe mal davon aus, dass die ID im Index steht, oder deine WHERE bedingung über den kompletten INDEX abgedeckt ist. Wenn dem so ist, wirst du in etwa gleiche performance haben, da mySQL nur nachgucken Lesen muss. sind sogar alle Spalten aus der WHERE bedingung und den Feldern die im SELECT stehen im INDEX greift mySQL ausschließlich auf den INDEX zu, der Tablespace wird nicht angepackt.
Muss allerdings mySQL aufgrund deiner WHERE-Bedinung viele Zeilen komplett aus dem Tablespace lesen, geht die performance weiter runter, desto mehr Daten gelesen werden müssen. Ganz schlimm ist dies bei einem Tablespacescan (hoffe das nennt man in mySQL so, wenn die ganze Tabelle gelesen werden muss). da macht es dann gravierende unterschiede ob man 500MB lesen muss, weil alles in einer Tabelle steht, oder ob man 10MB gelesen werden müssen, weil die Teilmenge der Daten die man lesen will in einer der 50Tabellen steht.
Ein gutes Indexdesign ist viel wert,... da ist es dann auch egal ob die Tabellenzeilen lang oder kurz sind,...

Original von knalli

Um mal dir zu verdeutlichen, was du machst: Wenn du alle Gebäude in der "HTML/PHP-Datei" schreibst, kannst du keine schnellen Erweiterungen machen. Das mindeste wäre also eine externe Konfiguration (bsp. Array) der Parameterdaten (eines Gebäudes), die man dynamisch auffüllen kann (und hier sind wir an einem Punkt, wo man fragen könnte.. wieso nicht DB?). Wenn aber alle Abfragen, Darstellungen an Ort und Stelle des Gebrauchs sind, ist der Code nicht wirklich erweiterbar, d.h. ein neues Features eines Gebäudes (Tür2) oder ein neues Gebäudetyp (Hochhaus) läßt sich nur mit Editierung von vielen Dateien realisieren.
Also, alle Gebäude, Einheiten, Fahrzeuge und Spezialisten stehen bei uns in PHP Dateien. wenn ich eine Einheit hinzufügen will, muss ich 1 einzige Datei ändern, indem ich diese zu der UNITS Datei hinzuhole,...
Warum soll ich überall da, wo ich alle einheiten brauche, die aus MYSQL holen? da kann ich mir auch das resultat nachdem ich alle gefetched habe, so weg speichern, und per include einbinden. Ausserdem, kann ich so, direkt an einer Stelle, auch programmcode für die einheiten einbauen. PHPCode in MYSQL und dann per eval halte ich für deutlich unperformant. (Lieber einmal include(units), als select * from units, while r=fetch, unit[]=r;,...)
Die Dateien sind so simpel, das ich die ruck zuck mit einem TextEditor bearbeiten kann, ich sehe hier keinen Vorteil für mySQL,....klar, wenn man die einheiten Reglmässig ändert, oder spieler eigene Einheiten entwerfen können ist das was anderes,...
wir arbeiten grade daran mehrsprachig werden zu können. Wenn ich mir jetzt noch überleg das ich neben der Sprachdatei, auch noch aufpassen muss, was in den Tabellen steht seh ich nur mehr aufwand.

Original von Sh1nto
Warum soll ich überall da, wo ich alle einheiten brauche, die aus MYSQL holen? da kann ich mir auch das resultat nachdem ich alle gefetched habe, so weg speichern, und per include einbinden.

Eine Anwendung wären z.B. SQL-Scripte, die man zur Analyse, aus Neugier etc. laufen läßt. Wenn ich da von jedem Anwender eine Aufstellung der Einheiten haben möchte, bekomme ich für den Typen leider nur eine ID, stehen die Einheiten-Typen in der DB, kann ich mit einem join, da den Namen der Einheit im erscheinen lassen.

Ein gutes Indexdesign ist viel wert,... da ist es dann auch egal ob die Tabellenzeilen lang oder kurz sind,...

Genau das hab ich gemeint.
Mir ist schon klar, dass ein full text search über ne 500 MB Tabelle länger braucht als über 10 MB
Gute Indixes sind sowieso das A und O von Tabellendesign..

Original von Sh1nto
Also, alle Gebäude, Einheiten, Fahrzeuge und Spezialisten stehen bei uns in PHP Dateien. wenn ich eine Einheit hinzufügen will, muss ich 1 einzige Datei ändern, indem ich diese zu der UNITS Datei hinzuhole,...

Das ist aber nur ein Anwendungsfall weil Ihr PHP mit mod_php laufen habt. Sobald Du an der technischen Basis aber was änderst, funktioniert das nicht mehr. Stellt man z.B. von mod_php auf FastCGI um, kann man soviel an den Daten ändern, wie man will. Die Anwendung bekommt davon nichts mit. bei anderen Sprachen ist das Problem das gleiche. wenn wir bei uns eine Datei ändern, heißt dass, ein komplettes Deployment zu machen. Daten ändern, Unittests laufen lassen, Spiel stoppen, Änderungen einspielen, Spiel neu starten. Dazu kommt noch, dass ich nicht wirklich Lust habe, dass das Team in den Quellen rum editiert.
Die Frage ist also nicht, ob man alles in der Datenbank speichert, sondern was der beste Weg für die gewählte Plattform ist. Und die zusätzlichen Datenbankabfragen kann man auch ganz eleganten in den Griff bekommen. Wir werden dafür vermutlich auf memchached setzen.

Frontend ist mod_php,... das backend aber nicht, das läuft über CLI. Das müssen wir auch stoppen und starten. Aber es kommt drauf an was man haben will.
Einheitenanzeige geht bei uns über das Admininterface,... ob ich da beim SELECT schon die Namen hole, oder bei der ausgabe $brk[$i]['name'], ist mir egal. Wichtiger ist mir, dass >99% aller Seitenaufrufe die statischen Informationen nutzen und somit die DB nicht zusätzlich belasten. Alle PHP Script liegen dank eAccelerator vorkompiliert im RAM, von daher denke ich, dass dies der performanteste weg,...
Wir lassen niemanden an die DB oder an Sourcedateien, ausser evtl. demnächst die Sprachdateien,...
(Das Backend irgendwann in einer nativen Programmmiersprache schreiben wär noch performanter, allerdings liegt unser CPU Verbrauch bei max. 20%, von daher hat das noch einges an Zeit,..)

Original von Sh1nto
Einheitenanzeige geht bei uns über das Admininterface,... ob ich da beim SELECT schon die Namen hole, oder bei der ausgabe $brk[$i]['name'], ist mir egal.

Du must Dich hier nicht rechtfertigen ;-) Du hast gefragt, warum man so etwas macht und ich habe ein Beispiel genannt. Softwareentwicklung ist immer das Abwägen von Vor- und Nachteilen, je mehr Vor- und Nachteile man kennt, um so besser wird die Entscheidung ausfallen ;-)

für statische daten mag eine textfile ja noch ausreichen..
aber was passiert, wenn
- jedes objekt im spiel dynamisch zusammensetzbar ist?
- viele komponenten z.b. an anderen dynamischen bedingungen hängen?
ums mal konkret zu machen:
wieso sollte ich eine gebäudeliste in einem php-array anlegen? nur damit ich es bei einem seitenaufruf von php arschlahm duchackern lassen soll? in sql mache ich ein einfaches:

select a,b,c from greferenz gr left outer join gebaeude g on (gr.gid=g.gid), user u where gr.vorraussetzung & u.vorraussetzung = gr.vorraussetzung and u.uid=xxx

(ist nur als pseudocode zu verstehen.. demozwecke eben )
mich würd mal interessieren, wie schnell eine php-only-lösung bei 300 forschungen und 50 waffen ist ..
das where in der obrigen abfrage ist theoretisch nur 1 cpu-tick pro zeile .. also viel schneller geht es ja wohl nicht..
ich würde xml/textfiles nur für ganz elementare variablen nehmen. In einer "richtigen" applikation (alse kein php ) würden die dann beim applikationsstart eingelesen und im ram gehalten.
Aber eine persistente speicherung geht eh an den meisten 08/15-php-spielen vorbei. Da muss man sich mit der datenbank behelfen.
Hätte ich mein Spiel in C++ geschrieben, dann wären die meisten Daten ohnehin nur im Speicher. ganz ohne Datenbank. Und zum speichern wird das dann "einfach" alle x min auf die platte gedumped. (alles nur theoretisch .. hab noch kein browsergame mit c++ gemacht )

Eine andere Möglichkeit wäre natürlich ein Join über ein Array oder über eine Xml-Datei.
Da dies schon die ersten Programmiertools bieten, könnte man ohne weiteres machen:
static BuildingInfo [] aoBuildings = IrgendwoherEingelese();
select * from tabelle INNER JOIN aoBuildings ON tabelle.type=aoBuildings.type; [Pseudo-Code]
Der Compiler baut dann ein schönes Konstrukt auf, das SQL-Datenbank, interne Speicherung und evtl Xml-Konfigurationen vereint. LINQ hat angefangen und ich denke, dass es nur eine Frage der Zeit ist bis weitere Programmierumgebungen folgen.
Bei Bedarf kann man die Arrays auch von der Laufzeitumgebung indizieren lassen. Ein weiterer Vorteil wäre die Parallelisierung. Während die SQL-Datenbank noch weitere Einträge sucht, kann das Programm sich schon um die Zuordnung des Arrays kümmern.

Ah.. du spielst auf LINQ an.
Muß echt mal das Buch durchlesen dazu. Soweit ich bisher sehen kann, würde mir LINQ eine Menge Arbeit abnehmen und ich könnte auch auf meine XML Files (ätsch) wieder einfacher zugreifen und müßte sie nicht über ein DataSet / XmlReader durchlutschen.
Nochmals... verwechselt die Anforderungen einer einfachen Anwendung wie ein Browsergame nicht mit denen einer komplexen Businessanwendung. Btw... ich arbeite bei einer Großbank, von daher meine Ausrichtung zum Thema XML und Co.

Original von Sh1nto
Also, erstmal sind es bei uns pro Server 41 Tabellen, plus 3 Tabellen, die für beide Server gelten,...

Original von Nuky
....
habe gerade zwei ca. gleichgroße tabellen von mir verglichen - eine 23 mb groß und ca. 5600 einträge, die andere 400 kb mit 6600 einträgen.
beide haben bei mehreren versuchen (verschiedene werte, um tabellencache zu umgehen) der ausgabe der id immer ~0.0007 sec gebraucht - für 30 reihen, die eingeschränkt wurden auf z.b. einen user... ist das einfach nur glück und ich bin ein idiot oder macht das eh nur beschränkt (und vor allem basierend auf der verwendungsart!) was?

Ich gehe mal davon aus, dass die ID im Index steht, oder deine WHERE bedingung über den kompletten INDEX abgedeckt ist. Wenn dem so ist, wirst du in etwa gleiche performance haben, da mySQL nur nachgucken Lesen muss. sind sogar alle Spalten aus der WHERE bedingung und den Feldern die im SELECT stehen im INDEX greift mySQL ausschließlich auf den INDEX zu, der Tablespace wird nicht angepackt.
Muss allerdings mySQL aufgrund deiner WHERE-Bedinung viele Zeilen komplett aus dem Tablespace lesen, geht die performance weiter runter, desto mehr Daten gelesen werden müssen. Ganz schlimm ist dies bei einem Tablespacescan (hoffe das nennt man in mySQL so, wenn die ganze Tabelle gelesen werden muss). da macht es dann gravierende unterschiede ob man 500MB lesen muss, weil alles in einer Tabelle steht, oder ob man 10MB gelesen werden müssen, weil die Teilmenge der Daten die man lesen will in einer der 50Tabellen steht.
Ein gutes Indexdesign ist viel wert,... da ist es dann auch egal ob die Tabellenzeilen lang oder kurz sind,...

Original von knalli

Um mal dir zu verdeutlichen, was du machst: Wenn du alle Gebäude in der "HTML/PHP-Datei" schreibst, kannst du keine schnellen Erweiterungen machen. Das mindeste wäre also eine externe Konfiguration (bsp. Array) der Parameterdaten (eines Gebäudes), die man dynamisch auffüllen kann (und hier sind wir an einem Punkt, wo man fragen könnte.. wieso nicht DB?). Wenn aber alle Abfragen, Darstellungen an Ort und Stelle des Gebrauchs sind, ist der Code nicht wirklich erweiterbar, d.h. ein neues Features eines Gebäudes (Tür2) oder ein neues Gebäudetyp (Hochhaus) läßt sich nur mit Editierung von vielen Dateien realisieren.
Also, alle Gebäude, Einheiten, Fahrzeuge und Spezialisten stehen bei uns in PHP Dateien. wenn ich eine Einheit hinzufügen will, muss ich 1 einzige Datei ändern, indem ich diese zu der UNITS Datei hinzuhole,...
Warum soll ich überall da, wo ich alle einheiten brauche, die aus MYSQL holen? da kann ich mir auch das resultat nachdem ich alle gefetched habe, so weg speichern, und per include einbinden. Ausserdem, kann ich so, direkt an einer Stelle, auch programmcode für die einheiten einbauen. PHPCode in MYSQL und dann per eval halte ich für deutlich unperformant. (Lieber einmal include(units), als select * from units, while r=fetch, unit[]=r;,...)
Die Dateien sind so simpel, das ich die ruck zuck mit einem TextEditor bearbeiten kann, ich sehe hier keinen Vorteil für mySQL,....klar, wenn man die einheiten Reglmässig ändert, oder spieler eigene Einheiten entwerfen können ist das was anderes,...
wir arbeiten grade daran mehrsprachig werden zu können. Wenn ich mir jetzt noch überleg das ich neben der Sprachdatei, auch noch aufpassen muss, was in den Tabellen steht seh ich nur mehr aufwand.
endlich mal einer mit mir einer meinung^^

musste dieser fullquote sein?

Original von Drezil
ums mal konkret zu machen:
wieso sollte ich eine gebäudeliste in einem php-array anlegen? nur damit ich es bei einem seitenaufruf von php arschlahm duchackern lassen soll? in sql mache ich ein einfaches:

select a,b,c from greferenz gr left outer join gebaeude g on (gr.gid=g.gid), user u where gr.vorraussetzung & u.vorraussetzung = gr.vorraussetzung and u.uid=xxx

(ist nur als pseudocode zu verstehen.. demozwecke eben )
mich würd mal interessieren, wie schnell eine php-only-lösung bei 300 forschungen und 50 waffen ist ..

Rein Interessehalber:
Du glaubst, dass das schicken vom SQL zum Server, das dortige Parsen und Analysieren, das Lesen und Vergleichen der Werte, das Zurückliefern der Werte und das danach folgende holen der Ergebnisse schneller ist, als die Ergebnisse direkt in einem Array zu speichern?
(Dazu: Kennst du den Overhead von einer TCP/IP-Verbindung..?)

Original von Drezil

das where in der obrigen abfrage ist theoretisch nur 1 cpu-tick pro zeile .. also viel schneller geht es ja wohl nicht..
1 Cpu-Tick pro zeile?
Hast du schon mal mit Assembler programmiert?

Original von Nuky
Du glaubst, dass das schicken vom SQL zum Server, das dortige Parsen und Analysieren, das Lesen und Vergleichen der Werte, das Zurückliefern der Werte und das danach folgende holen der Ergebnisse schneller ist, als die Ergebnisse direkt in einem Array zu speichern?

nein. aber deutlich wartungsärmer bei verschachtelungen, bedingten vererbungen und rechenoperationen auf allen datensätzen vor der ausgabe. wenn ich das in einem php-array halten würde und den jedes mal mit nem foreach o.ä. durchgehe, dann wird das ganz schnell kriminell. Außerdem gibt es noch weitere nettigkeiten wie einen query-cache etc. die man in php erst mühsam per hand erstellen müsste.
außerdem habe ich von dynamischen daten gesprochen. Für statische sachen ist eine textfile (mit z.b. php-array) ca. genauso fix wie ne db..

(Dazu: Kennst du den Overhead von einer TCP/IP-Verbindung..?)
jop. und daher nutze ich auch persistente datenbankverbindungen damit die verbindung nicht immre neu aufgebaut werden muss.

1 Cpu-Tick pro zeile?

Hast du schon mal mit Assembler programmiert?
ich sagte THEORETISCH. Das man da in echt nicht dran kommt ist ja sowas von klar. Ich kenne dieses imho eklige asm-geschubse .. richtig programmiert hab ich es noch nicht, aber in der theorie schon mehrfach durchgenommen ..
ich bezog mich auch eher darauf, dass ein abgleich mit z.b. einem php-array oder einer unoptimierten db-struktur gleich einen crossjoin verursacht, welcher den server schnell in die knie zwingen dürfte.
wie gesagt. ich finde datenbanken sinnig, wenn man z.b. mit php arbeitet, wo man daten nicht persistent halten kann oder man umgebungen mit mehreren von einander unabhängigen instanzen von clients auf denselben daten arbeitet.
eine "ich halt alles im ram"-lösung ist immer das tollste.. und wenn es um eine fest abgegrenzte aufgabe geht kann man auch gerne auf eine datenbank verzichten.
noch ein grund keine textfiles auf daten zu nutzen, die man viel benötigt: schon mal überlegt wie lange der zugriff auf eine datei um fs dauert? eine datenbank hält solche sachen automatisch im ram vor ohne dass ich mich explizit darum kümmern muss.

> eine datenbank hält solche sachen automatisch im ram vor ohne dass ich mich explizit darum kümmern muss.
> schon mal überlegt wie lange der zugriff auf eine datei um fs dauert?
Ein Betriebssystem hält solche sachen automatisch im Ram vor ohne dass ich mich explizit darum kümmern muss. (Nennt sich Dateicache)

Letzter Kommentar von mir, danach bin ich weg...
Man merkt bei einigen das sie nur das sogenannte "Buch Wissen" besitzen und dies als das A und O für sich definiert haben.

oups, da hab ich ja was losgetreten,...
unser tabellenlayout sieht so aus, das in einer Zeile, für jede Einheit eine Spalte ist, da wäre das mit dem join eh schwieriger (fällt mir grade mal so auf),... dies ist die flottentabelle,...
wenn es darum ginge viele unterscheidliche Einheiten, und nicht massen von Einheiten + wenigen Arten, abzulegen macht das ganze Sinn, würde ich dann ähnlich machen, zumal dann wahrscheinlich abzusehen ist, das es ist nicht normal ist, das immer fast alle Einheitentypen gleichzeitig verschickt werden (Was ja dann immer 300Inserts/Deletes + 300 Updates wären), sondern nur ein paar davon. Die kann man sich dann auch mal ebend fetchen. Und wenn der Server sauber konfiguriert ist, liegen die dann im QueryCache. Obwohl ich bei so statischen informationen in der Menge, evtl. doch eine Ramdisk, oder Memory Maped Files nehmen würde, wo ich direkt positionieren kann,...

Man merkt bei einigen das sie nur das sogenannte "Buch Wissen" besitzen und dies als das A und O für sich definiert haben.
Wenn sie dabei noch tolerant zu anderen Lösungen sind, ist das doch ok jeder muss mit seinen Entscheidungen und den konsequenzen ja schließlich selber leben
Und es ging mir in meiner ersten Aussage eigentlich nur darum, zu zeigen, das auch eine umsetzung mit PHP-Dateien, nicht gleichzeitig viel Aufwand bedeutet,... sondern je nach Anwendungsgebiet, vielleicht Sinn macht, oder keinen. In unserem Fall macht es auf jeden Fall sinn. Im Fall von Drezil, wahrscheinlich nicht
Vielleicht macht es auch sinn, alle Einheiten, Gebäude, als ein Array von Objekten abzulegen,... sei es direkt in PHP oder in einer ?ObjektDatenbank? oder wie heißen die dinger?

Original von TheUndeadable
Ein Betriebssystem hält solche sachen automatisch im Ram vor ohne dass ich mich explizit darum kümmern muss. (Nennt sich Dateicache)

Naja...also so einfach ist es auch wieder nicht. Der Cache bringt nur sehr bedingt etwas und ist keinesfalls mit der RAM-Version zu vergleichen. Zumal da keine gesamten Textdateien im RAM liegen - für solche Szenarien hat uns Gott den B*-Baum gegeben als Datenstuktur.
Ich will die PHP-only Version keinesfalls gut reden, aber das Argument dagegen hinkt doch gewaltig finde ich. Sieht man es auf Softwareentwicklungssicht: Performance ist sicher nicht alles, Kapselung und Erweiterbarkeit sind eben auch nicht unwichtig.
Bin jetzt nicht so extrem tief in PHP, aber ist das überhaupt threadsicher?
@MrMarco: du hast Post seit gestern

Original von SamsonBin jetzt nicht so extrem tief in PHP, aber ist das überhaupt threadsicher?

Innerhalb einer PHP-Datei kann man keine weiteren Threads starten (wie das mit cli ist weiß ich nicht). Der Webserver hat für jede Anfrage einen eigenen Thread bzw. Handle. Wenn der Webserver threadsicher ist, sollten die PHP-Dateien das auch
// Hab grad mal bei php.net gesucht:
de3.php.net/manual/de/install.unix.apache2.php

Anmerkung: Um eine Multithreaded Version von Apache zu erzeugen, muss Ihr System Threads unterstützen. Dies impliziert, dass Sie PHP mit der experimentellen Zend Thread Safety (ZTS) bauen. Deshalb könnten nicht alle Erweiterungen verfügbar sein. Die empfohlene Einstellung ist es, Apache mit dem prefork MPM-Modul zu bauen.

de3.php.net/manual/de/faq.installation.php#faq.installation.apache2

53.1. Warum sollte ich Apache2 mit threaded MPM nicht in einer Produktions-Umgebung verwenden?

PHP ist Klebstoff. Es ist der Klebstoff, der verwendet wird, um coole Web-Anwendungen zu erstellen indem er dutzende von Bibliotheken von Drittanbietern zusammenklebt und sie über eine intuitiv und einfach erlernbare Schnittstelle als zusammenhängende Einheit erscheinen lässt. Die Flexibilität und die Mächtigkeit von PHP sind auf die Stabilität und Robustheit der zugrunde liegenden Plattform angewiesen. Es braucht ein funktionierendes Betriebssystem, einen funktionierenden Webserver und funktionierende Bibliotheken Dritter, um zusammen zu kleben. Wenn eines davon nicht mehr funktioniert, braucht PHP Wege, um die Probleme erkennen und schnell beheben zu können. Wenn Sie das zugrunde liegende Gerüst dadurch komplexer machen, dass Sie keine völlig voneinander getrennten Ausführungsthreads und Speichersegmente und keine starke Sandbox für jede einzelne Anfrage haben, stellen Sie das System von PHP auf tönerne Füße.
Falls Sie das Gefühl haben, theaded MPM benutzen zu müssen, sollten Sie nach einer FastCGI-Konfiguration schauen, in der PHP in seinem eigenen Speicherbereich läuft.
Und schließlich: diese Warnung gegen die Verwendung von threaded MPM gilt nicht so stark für Windows-Systeme, weil die Bibliotheken auf dieser Plattform tendenziell threadsicher sind.
Damit habe ich mich nie auseinandergesetzt, ich weiß noch nichtmal was threaded MPM ist