Accountinformation speichern

hustbaer

@EineFrageHabIch
Ich denke den Antworten von Shade und tntnet ist nicht viel hinzuzufügen.
SQL Datenbanken sind oft eine gute Wahl. Um genaueres zu sagen müsste man mehr über das Projekt wissen.

Stichwort Datenbankmodellierung

CrispyTurtleAlligator

EineFrageHabIch schrieb:

Hi,

ja genau das meine ich ja. Dann ganz spezifisch: Ich möchte die Kartensammlung eines Spieler Serverseitig speichern, wie mache ich das am Besten?

Dann würde ich mal schleunigst anfangen zum Beispiel eine serverseitige Programmiersprache zu lernen. Dafür eignet sich PHP. Zudem brauchst du einen Speicherort für die Daten. Dafür bieten sich simple Dateien oder viel besser MySQL Datenbanken an.

DarkShadow44

@CrispyTurtleAlligator
Meinst du das ist nach 5 Monaten noch relevant?

CrispyTurtleAlligator

DarkShadow44 schrieb:

@CrispyTurtleAlligator
Meinst du das ist nach 5 Monaten noch relevant?

Für andere, die in der Lage sind Google oder Suchen zu nutzen, bestimmt. Vorausgesetzt man hat dasselbe Problem.

Tatsächlich bin ich beim regelmäßigen durchstöbern des Forums auf meinen eigenen Thread gekommen und gebe kurz Feedback, was ich getan habe:
1. Ich habe mir einen Kostenlosen webhost gesucht (www.000webhost.com)
2. Ich habe angefangen php zu lernen und eine mySQL-Datenbank angelegt über links derselben Website. Die Verwaltung läuft über phpMyAdmin.

Da meine Zeit knapp ist, komme ich auch nur langsam voran und bin dabei die Korrelation die Shade Of Mine erwähnt hat umzusetzen. Freigeschaltete Karten könnte man entweder über eine Bitmaske "0101001...." realisieren wenn man wirklich geizig ist mit dem Platz. Oder einen Eintrag für jede Karte in der Datenbank anlegen. Da weis ich noch nicht was gut / sinnvoll / praktikabel / zukunftssicher ist.

thejeff

Um das Lernen wirst du wohl nicht herumkommen, auch wenn es Zeit kostet. Bitmaske ist dafür eher ungeeignet.

Ich würde dafür folgende Datenbankschema verwenden.

Users
------
id
login
...

Cards
------
id
name
...

UsersCards
------
userId
cardId

Damit hast du keine Limitierung in der Anzahl der Karten. Und so kannst du jedem Nutzer beliebig viele Karten zuweisen und diese Zuweisung auch wieder entfernen.

Shade Of Mine

Das kommt auf die Menge der Karten an. Eine Bitmaske kann durchaus Sinn machen. Die Relation mit Users und Cards ist nett und sehr schön - aber uU nicht effizient. Hängt halt von den Umständen ab.

thejeff

Shade Of Mine schrieb:

Das kommt auf die Menge der Karten an. Eine Bitmaske kann durchaus Sinn machen. Die Relation mit Users und Cards ist nett und sehr schön - aber uU nicht effizient. Hängt halt von den Umständen ab.

Ich kenne mich bei diesen ganzen Magic-Kartenspielen nicht so aus. Aber ich bin immer davon ausgegangen, dass es dort mehr als 50 verschiedene Karte gibt. Aber bei einer überschaubaren Anzahl hast du Recht. Was meinst du mit "aber uU nicht effizient"? Performance? Ich würde die Zuordnung dann einfach eine Ebene darüber cachen.

Shade Of Mine

thejeff schrieb:

Shade Of Mine schrieb:

Das kommt auf die Menge der Karten an. Eine Bitmaske kann durchaus Sinn machen. Die Relation mit Users und Cards ist nett und sehr schön - aber uU nicht effizient. Hängt halt von den Umständen ab.

Ich kenne mich bei diesen ganzen Magic-Kartenspielen nicht so aus. Aber ich bin immer davon ausgegangen, dass es dort mehr als 50 verschiedene Karte gibt. Aber bei einer überschaubaren Anzahl hast du Recht. Was meinst du mit "aber uU nicht effizient"? Performance? Ich würde die Zuordnung dann einfach eine Ebene darüber cachen.

Und wie cacht du? Mit einer bitmaske.

Domain Specific Optimizations sind das effektiveste was es an Optimierungen gibt. Denn man kann die Domain Specific Daten sehr kompakt speichern. Wenn man weiß dass es exakt N karten gibt und der User hat die Karte entweder oder er hat sie nicht, ist eine Bitmaske enorm effizient. Ist es immer das beste? Mit Sicherheit nicht. Relationale Datenbanken sind schön im Design aber halt leider auch lahm. Ist das immer ein Problem? Mit Sicherheit nicht.

thejeff

Shade Of Mine schrieb:

Und wie cacht du? Mit einer bitmaske.

Domain Specific Optimizations sind das effektiveste was es an Optimierungen gibt. Denn man kann die Domain Specific Daten sehr kompakt speichern. Wenn man weiß dass es exakt N karten gibt und der User hat die Karte entweder oder er hat sie nicht, ist eine Bitmaske enorm effizient. Ist es immer das beste? Mit Sicherheit nicht. Relationale Datenbanken sind schön im Design aber halt leider auch lahm. Ist das immer ein Problem? Mit Sicherheit nicht.

In dem speziellen Fall hast du mit Bitmasken natürlich Recht.

Cachen würde ich im Fall der Relationen so indem ich die Daten des Users fetche, dann die ihm gehörenden Karten. Das ganze verpacke ich dann schön in Objekte (einzeln oder als großes Objekt mit Unterobjekten) und speichere das ganze z.B. in Redis oder Memcache. Beim nächsten Mal hole ich alles auf dem Cache um spare mit den Datenbankzugriff.
Welche Implementierung man letztendlich nimmt, hängt immer stark von der jeweiligen Anwendung ab.

Shade Of Mine

thejeff schrieb:

Cachen würde ich im Fall der Relationen so indem ich die Daten des Users fetche, dann die ihm gehörenden Karten. Das ganze verpacke ich dann schön in Objekte (einzeln oder als großes Objekt mit Unterobjekten) und speichere das ganze z.B. in Redis oder Memcache. Beim nächsten Mal hole ich alles auf dem Cache um spare mit den Datenbankzugriff.
Welche Implementierung man letztendlich nimmt, hängt immer stark von der jeweiligen Anwendung ab.

Das ist schön vom Design her und oft eine gute Sache.

Ich sage nicht dass man standardmäßig Bitmasken verwenden soll - sondern dass sowas eben eine gute Lösung sein kann. idR würde ich aber nicht Redis für einen SQL Cache verwenden. Dann packe ich die Daten gleich in Redis.

thejeff

Sollte jetzt auch keine Kritik an deinem Vorschlag oder Bitmasken sein. Einigen wir uns einfach darauf, dass beide Lösungen je nach Anwendungsfall ihre Daseinsberechtigung haben