Also ich habe 2 Tabellen...
In der einen Tabel stehen die Itemarten drinne also
Ringe/schwerter/etc
und in der anderen Tabelle sind die items welche die user haben....
und die spalte itemid steht dann dafür was fürn item
in der wo die verschiedenen itemtypen sind wird nochmal unterteilt in schwerter, schilder, anwendbare items etc...
nun will ich im inventar aufteilen
das heisst auf einer seite nur schwerter etc.....
nun hab ich verschiedene möglichkeiten....
ich kann die itemarten tabelle auslesen und itemart für itemart abegehen und abfragen wieviele items der user von dieser art hat.....
oder ich frage gleich die items ab und lese von dem user alle items aus, gucke nach den itemarten und gehe diese nochmal ab......
ich hoffe es hat mich jemand verstanden xDDD
also welcher weg wäre da eigentlich rein rechnerisch schneller?
Was ist schneller
gepostet vor 17 Jahre, 8 Monate von Kapsonfire
gepostet vor 17 Jahre, 8 Monate von Nuky
rein intuitiv wäre mein weg zuerst alles abfragen und dann ausgeben.
wenn du die daten noch nachsortieren willst etc., könnte es schneller sein der datenbank das sortieren zu überlassen und mehrere abfragen zu machen. prinzipiell tendiere ich aber (auch aus erfahrung) dazu, die abfragen gering zu halten und sowas in der jeweiligen skriptsprache zu erledigen.
wenn du die daten noch nachsortieren willst etc., könnte es schneller sein der datenbank das sortieren zu überlassen und mehrere abfragen zu machen. prinzipiell tendiere ich aber (auch aus erfahrung) dazu, die abfragen gering zu halten und sowas in der jeweiligen skriptsprache zu erledigen.
gepostet vor 17 Jahre, 8 Monate von Kapsonfire
so hatte ich das auch schon vorher... aber wenn ich ganz viele verschiedene items mache... nehmen wir mal an so ca. 50000 wird das doch irgendwann mal langsamer....
gepostet vor 17 Jahre, 8 Monate von Klaus
Das solltest du natürlich nicht machen. Ein Array mit einigen Hundert Elementen würde ich maximal von PHP laden lassen. Denn der Interpreter hat die Eigenschaft bei großen Arrays sehr viel RAM zu verbrauchen, was zum Tod des Skriptes führen kann.
Die Datenbank wäre hier die bessere Lösung, weil PHP nicht immer alle Daten laden muss, die du wahrscheinlich gar nicht komplett benötigst.
Die Datenbank wäre hier die bessere Lösung, weil PHP nicht immer alle Daten laden muss, die du wahrscheinlich gar nicht komplett benötigst.
gepostet vor 17 Jahre, 8 Monate von Nuky
Ich dachte nicht, dass deine Charaktere soviele Items tragen. Ich dachte an Mengen an ~50...
Ich bin sowieso meist in der gecachten und vorkompilierten Welt unterwegs, daher auch mein starker Fokus das in PHP zu lösen
Ich bin sowieso meist in der gecachten und vorkompilierten Welt unterwegs, daher auch mein starker Fokus das in PHP zu lösen
gepostet vor 17 Jahre, 8 Monate von Klaus
50k wird vielleicht noch gehen.
Ich hab mal versucht in PHP ein einfaches Array mit eine Mio. Elementen zu deklarieren. (Schlüssel Int, Inhalt Bool). Dafür braucht der Prozess satte 250 MB Speicher und in jeder effektiveren Sprache reicht 1 MB:
Ich hab mal versucht in PHP ein einfaches Array mit eine Mio. Elementen zu deklarieren. (Schlüssel Int, Inhalt Bool). Dafür braucht der Prozess satte 250 MB Speicher und in jeder effektiveren Sprache reicht 1 MB:
gepostet vor 17 Jahre, 8 Monate von None
HMmm... in dem Fall, aber in eine Tabelle damit. MySQL bietet doch diese netten HEAP-Tables an. Vielleicht hilft dir das ein wenig weiter.
gepostet vor 17 Jahre, 8 Monate von Xfer
Wie wäre es mit einem JOIN?
Bsp:
SELECT
ITEMID,
ITEMNAME,
ITEMTYPE
FROM
TBL_USRITEMS
LEFT JOIN
TBL_ITEMS
ON
TBL_USRITEMS.ITEMID = TBL_ITEMS.ID
WHERE
USERID = XXX
Den Rest kann dann PHP erledigen
cu
Xfer
Bsp:
SELECT
ITEMID,
ITEMNAME,
ITEMTYPE
FROM
TBL_USRITEMS
LEFT JOIN
TBL_ITEMS
ON
TBL_USRITEMS.ITEMID = TBL_ITEMS.ID
WHERE
USERID = XXX
Den Rest kann dann PHP erledigen
cu
Xfer
gepostet vor 17 Jahre, 7 Monate von Shackleton
Kommt ein bisschen darauf an welche Datenmengen pro Abfrage anfallen und welche Abfragen im Spiel am häufigsten anfallen.
Die schnellste Lösung wäre nach meiner Ansicht:
-Im ITEMS Table die PLAYER_ID zu indizieren
-Im ITEMS Table nochmal die Kategorie-Information redundant zu speichern. Also du verwendest einen Tinyint der die Oberkategorie des Items (0 fuer Schwerter, 1 für Schilde ...) nochmal spiegelt.
die Abfrage der DB sollte dann sehr simpel und sehr schnell sein. (irgendsowas wie SELECT * FROM blah WHERE player_id = blah AND CATEGORIE = 0)
Die schnellste Lösung wäre nach meiner Ansicht:
-Im ITEMS Table die PLAYER_ID zu indizieren
-Im ITEMS Table nochmal die Kategorie-Information redundant zu speichern. Also du verwendest einen Tinyint der die Oberkategorie des Items (0 fuer Schwerter, 1 für Schilde ...) nochmal spiegelt.
die Abfrage der DB sollte dann sehr simpel und sehr schnell sein. (irgendsowas wie SELECT * FROM blah WHERE player_id = blah AND CATEGORIE = 0)
gepostet vor 17 Jahre, 7 Monate von Itchy
Meine Lösung wäre: den Itemtyp als ENUM in die Tabelle speichern (MySQL zumindest kann das) und in die ENUM Elemente in der Reihenfolge deklarieren, wie Du sie brauchst.
Also z.B.
CREATE TABLE items (
INT id,
ENUM( 'sword', 'shield', 'potion' ) item_type,
VARCHAR(100) name
[...]
)
CREATE TABLE inventory (
INT player_id,
INT item_id
[...]
)
Dann sähe die Abfrage wie folgt aus:
SELECT * FROM items, inventory WHERE player_id=12345 AND items.id=inventory.item_id ORDER BY item_type, name
Willst Du nur die reine Anzahl wissen je Typ:
SELECT item_type, count(*) FROM items, inventory WHERE player_id=12345 AND items.id=inventory.item_id GROUP BY item_type ORDER BY item_type
Also z.B.
CREATE TABLE items (
INT id,
ENUM( 'sword', 'shield', 'potion' ) item_type,
VARCHAR(100) name
[...]
)
CREATE TABLE inventory (
INT player_id,
INT item_id
[...]
)
Dann sähe die Abfrage wie folgt aus:
SELECT * FROM items, inventory WHERE player_id=12345 AND items.id=inventory.item_id ORDER BY item_type, name
Willst Du nur die reine Anzahl wissen je Typ:
SELECT item_type, count(*) FROM items, inventory WHERE player_id=12345 AND items.id=inventory.item_id GROUP BY item_type ORDER BY item_type
gepostet vor 17 Jahre, 7 Monate von Kapsonfire
Original von Shackleton
Kommt ein bisschen darauf an welche Datenmengen pro Abfrage anfallen und welche Abfragen im Spiel am häufigsten anfallen.
Die schnellste Lösung wäre nach meiner Ansicht:
-Im ITEMS Table die PLAYER_ID zu indizieren
-Im ITEMS Table nochmal die Kategorie-Information redundant zu speichern. Also du verwendest einen Tinyint der die Oberkategorie des Items (0 fuer Schwerter, 1 für Schilde ...) nochmal spiegelt.
die Abfrage der DB sollte dann sehr simpel und sehr schnell sein. (irgendsowas wie SELECT * FROM blah WHERE player_id = blah AND CATEGORIE = 0)
genauso habe ich das gelöstz ausser das ich categorie auf enum habe um die mit programmierer zu schonen^^
gepostet vor 17 Jahre, 7 Monate von Eckstoss
Viele Programmierer meinten zu mir, dass "Enum" veraltet sei und deshalb kaum benutzt wird..stimmt den dass? Oder benutzt ihr es teilweisse auch?
gepostet vor 17 Jahre, 7 Monate von Fornax
Ob veraltet oder nicht - Ich benutze es ständig. außerdem rät einem MySQL sogar, enums aufgrund der Performance zu benutzen.
gepostet vor 17 Jahre, 7 Monate von Nuky
Enum veraltet?
char * ist veraltet, da es Strings gibt.
Den, der behauptet das Enums alt sind, schickst du mal zurück in die Uni - er soll sein Fach mal lernen..
char * ist veraltet, da es Strings gibt.
Den, der behauptet das Enums alt sind, schickst du mal zurück in die Uni - er soll sein Fach mal lernen..
gepostet vor 17 Jahre, 7 Monate von None
Original von Eckstoss
Viele Programmierer meinten zu mir, dass "Enum" veraltet sei und deshalb kaum benutzt wird..stimmt den dass? Oder benutzt ihr es teilweisse auch?
Denk mal nach was ein Enum intern darstellt.
Du brauchst genau eine Tabelle in der steht 1 = Pommes, 2 = Schnitzel, 3 = Salat
Jeder Eintrag in die Tablle muss jetzt also nur noch 1,2 oder 3 gesichert werden. Dazu brauch man nun 2 Bits. Für den String "Pommes" oder gar eine einstellige (unsigned) Zahl braucht man wesentlich mehr.
Was gibt es also besseres als Enums zu haben? Genau, nichts
In Java wie in anderen Hochsprachen gehören Enums zum Standard. Wer will denn auch schon if( error.code == 22) abfragen?
if( error.code == meineKlasse.FALSCHE_EINGABE) ist da doch viel selbstredender. Zumal wenn man sich was an den Fehlercodes ändert ist die erste Abfrage falsch und muss verbessert werden. Letztere Möglichkeit funktioniert dank Enum immer
gepostet vor 17 Jahre, 7 Monate von Eckstoss
Vielen Dank für die Aufklärung.
Habe nämlich mit ENUM auch immer gearbeitet, bis ein Kollege von mir meinte diese wäre total Veraltet und sollte man nicht so verwenden.
GN - Da werden Sie geholfen
Habe nämlich mit ENUM auch immer gearbeitet, bis ein Kollege von mir meinte diese wäre total Veraltet und sollte man nicht so verwenden.
GN - Da werden Sie geholfen
gepostet vor 17 Jahre, 7 Monate von Itchy
In Java wie in anderen Hochsprachen gehören Enums zum Standard. Wer will denn auch schon if( error.code == 22) abfragen?
Autsch, autsch, autsch - Errorcodes in Java? Schon mal von was Exceptions gehört?
Java Enums sind ganz praktisch, aber macht bitte keine Errorcodes draus, das ist so C
gepostet vor 17 Jahre, 7 Monate von None
Original von Itchy
In Java wie in anderen Hochsprachen gehören Enums zum Standard. Wer will denn auch schon if( error.code == 22) abfragen?
Autsch, autsch, autsch - Errorcodes in Java? Schon mal von was Exceptions gehört?
Java Enums sind ganz praktisch, aber macht bitte keine Errorcodes draus, das ist so C
Das war auch auf Hochsprachen allgemein bezogen...zu Exceptions gibts schon ne eigenen Beitrag