Ich plane mein Itemsystem neu zu gestallten, und dabei sind mir einige grundsätzliche Fragen in den Kopf geschossen:
Ist es besser eine große Tabellen zu haben oder mehrere Kleine?
eine große Tabelle:
- unterscheidung des Itemtyps durch eine Spalte
viele (4) kleine Tabellen:
- unterscheidung des Itemstyps durch die Tabelle selbst
Meine jetzige Itemtabelle hat ~200k Zeilen - und das kommt mir schon ein wenig viel vor.
MYSQL - viele kleine VS wenig große
gepostet vor 19 Jahre, 7 Monate von MannaZ
gepostet vor 19 Jahre, 7 Monate von Mudder
Was meinst du mit Item-Tabellen? Was sie Spieler bei sich im Rucksack haben?
Also ich würde das alles in eine Tabelle stecken. Artikel-ID, "Rucksack"-ID und.. das kommt aber auf deine Spielstruktur an noch eine Menge.
Die Menge der Datensätze ist natürlich ne ganzer Haufen und evtl. solltest du überlegen nicht die Datenbank zu wechseln..
Also ich würde das alles in eine Tabelle stecken. Artikel-ID, "Rucksack"-ID und.. das kommt aber auf deine Spielstruktur an noch eine Menge.
Die Menge der Datensätze ist natürlich ne ganzer Haufen und evtl. solltest du überlegen nicht die Datenbank zu wechseln..
gepostet vor 19 Jahre, 7 Monate von Gambler
Für die Datenbank wären mehrere Tabellen performanter.
gepostet vor 19 Jahre, 7 Monate von MannaZ
Original von Mudder
Was meinst du mit Item-Tabellen? Was sie Spieler bei sich im Rucksack haben?
Nicht direkt im Rucksack - bei meinem Spiel kann man sich Hüte, Schuhe, Waffen und andere "Gebrauchsgegenstände kaufen, und ich plane diese so einzuteilen:
Je eine Tabelle für:
- Items die der User gerade angelegt hat
- Items die der User bei sich zu hause liegen hat (nicht angelegt)
- Items auf dem Markt
- Items die in der Stadt verteilt sind
und wenn jetzt ein User ein item anlegt soll dieses von der einen Tabelle in die andere verschoben werden.
Natürlich werde ich zum erstellen der Items eine "Eingangs" - Tabelle anlegen, mit auto-increment, um eine Unique-ID zu gewährleisten.
Original von Mudder
Die Menge der Datensätze ist natürlich ne ganzer Haufen und evtl. solltest du überlegen nicht die Datenbank zu wechseln..
Ich verwende PHP, was für eine Datenbank würdest du mir empfehlen
gepostet vor 19 Jahre, 7 Monate von elzair
Also ich hab das so:
-Tabelle für alle Items der User (aktive und nicht aktive Items)
-Tabelle für alle Items, die auf dem Markt sind
und die Items, die in den Städten verteilt sind würde ich in deinem Fall auch extra machen
-Tabelle für alle Items der User (aktive und nicht aktive Items)
-Tabelle für alle Items, die auf dem Markt sind
und die Items, die in den Städten verteilt sind würde ich in deinem Fall auch extra machen
gepostet vor 19 Jahre, 7 Monate von Kampfhoernchen
Jep. Das ist wohl die beste Lösung.
Für jeden Ort eine eigene Tabelle zu machen, ist glaube ich ein wenig unsinnig, auch wenn es (vielleicht???) schneller ist.
Für jeden Ort eine eigene Tabelle zu machen, ist glaube ich ein wenig unsinnig, auch wenn es (vielleicht???) schneller ist.
gepostet vor 19 Jahre, 7 Monate von HSINC
wenn das format starr ist und die tab gut indiziert, sehe ich eigentlich gar keinen geschwindigkeitsvorteil das auf mehrere tabs aufzuteilen, wenn sie dynamisch ist, hängt es wohl auch noch von der anzahl der offenen tabs und der config des serveres ab.
auch denke ich das das dann oft vorkommende insert und delete über mehrer tabs den selectvorteil deutlich reduzieren wird (je nach indizes und häufigkeit). dann kommt auch noch die frage nach der konsistenz dazu.
persönlich würde ich es in einer tab lassen, einfach aufgrund der handhabbarkeit. und 200k zeilen sind nicht wirklich viel
auch denke ich das das dann oft vorkommende insert und delete über mehrer tabs den selectvorteil deutlich reduzieren wird (je nach indizes und häufigkeit). dann kommt auch noch die frage nach der konsistenz dazu.
persönlich würde ich es in einer tab lassen, einfach aufgrund der handhabbarkeit. und 200k zeilen sind nicht wirklich viel
gepostet vor 19 Jahre, 7 Monate von Gambler
Mh naja ich kenns jetzt halt auch nur von DBs mit 50.000.000 Einträgen. Da geht irgendwann gar nix mehr. Deßhalb backuppen wir die regelmässig und fangen neu an. Haben dann halt mehrere aber mehr Geschwindigkeit.
gepostet vor 19 Jahre, 7 Monate von felix
Ich würd mal sagen kommt darauf an in welcher Form diese Tabellen dann von Scripten oder Tickern aufgerufen werden. Wenn eh bei jedem Script fast alle Tabelle abgefragt werden müssen, kann man weniger/grössere Tabellen machen
Wenn ein Index da ist, und der Select sich nach diesem richtet, spielt die grösse eigentlich eine unwesentliche Rolle. 4mal ne Suche durch 50'000 Datensätze dauert dann ganz sicher länger als 1 Suche durch 200'000 Datensätze. Es ist aber nicht zu unterschätzen welche Bedinungen man in die SQL schreibt. Eine Suche wie "...where a like '123%' or b ='2' group by c order by bla bla" sollte man nicht auf allzu grosse Tabellen anwenden. :wink:
Wenn ein Index da ist, und der Select sich nach diesem richtet, spielt die grösse eigentlich eine unwesentliche Rolle. 4mal ne Suche durch 50'000 Datensätze dauert dann ganz sicher länger als 1 Suche durch 200'000 Datensätze. Es ist aber nicht zu unterschätzen welche Bedinungen man in die SQL schreibt. Eine Suche wie "...where a like '123%' or b ='2' group by c order by bla bla" sollte man nicht auf allzu grosse Tabellen anwenden. :wink:
gepostet vor 19 Jahre, 6 Monate von onny
Ich hab zu jedem itemtyp eine Tabelle und dann nochmal auf spieler und npcs aufgeteilt:
items_weapons_players
items_weapons_npcs
items_boots... usw
die struktur is fast in jeder die selbe bis auf weapons die hat noch mindmg und maxdmg. Wo sich das item befindet ist in einem feld, in dem item datensatz geschrieben.
Zieht der user ein item an, veraendert in der item tabelle nichts, nur in der usertabe.lle (eqp_ring1 = ringid) veraendert man aber den ort (inventar-schrank-shop...) dann veraendert sich ein feld im entsprechenden itemtabellen datensatz.
ob das nun so dem optimum entspricht kann ich nicht sagen, wenn jemand einen verbesserungsvorschlag hat immer her damit
items_weapons_players
items_weapons_npcs
items_boots... usw
die struktur is fast in jeder die selbe bis auf weapons die hat noch mindmg und maxdmg. Wo sich das item befindet ist in einem feld, in dem item datensatz geschrieben.
Zieht der user ein item an, veraendert in der item tabelle nichts, nur in der usertabe.lle (eqp_ring1 = ringid) veraendert man aber den ort (inventar-schrank-shop...) dann veraendert sich ein feld im entsprechenden itemtabellen datensatz.
ob das nun so dem optimum entspricht kann ich nicht sagen, wenn jemand einen verbesserungsvorschlag hat immer her damit
gepostet vor 19 Jahre, 6 Monate von Teonas
Ich bin auch für die Lösung mit mehreren Tabellen, da sich das Ganze unter Stress ein wenig besser verhält, wenn es MyISAM-Tabellen sind.
Dann sperrt ein UPDATE/INSERT nur eine Tabelle, die anderen drei sind noch für Requests frei. Für SELECTs ist die Aufteilung relativ egal, die sollten immer gleich schnell sein.
Ein weiterer Vorteil bei mehreren Tabellen sind kleinere Indices, die dann bei einer Modifikation schneller aktualisiert werden. Damit sind INSERTs und UPDATEs generell schneller. Das gilt generell für alle Datenbanken, nicht nur für MySQL/MyISAM.
Dann sperrt ein UPDATE/INSERT nur eine Tabelle, die anderen drei sind noch für Requests frei. Für SELECTs ist die Aufteilung relativ egal, die sollten immer gleich schnell sein.
Ein weiterer Vorteil bei mehreren Tabellen sind kleinere Indices, die dann bei einer Modifikation schneller aktualisiert werden. Damit sind INSERTs und UPDATEs generell schneller. Das gilt generell für alle Datenbanken, nicht nur für MySQL/MyISAM.