Spigot Virtuelle Inventare am besten speichern. MySQL möglich / sinnvoll ?

[Addycted]

Huhu,
ich bin aktuell dabei mir Backpacks zu programmieren, die sogesehen nur virtuelle Inventare sind, welche in einer HashMap gespeichert werden.
Jetzt hatte ich eigentlich vor, diese in MySQL zu speichern, d.h. die Items innerhalb des Backpacks. Die Backpacks sollten nicht an einen Spieler gebunden sein und auch mit Inhalt getauscht werden können (die Backpacks sind eigene Items).

Ich habe jetzt schon eine ziemlich gute Zeit nach irgendwelchen Lösungen dazu gegooglet, bin mir aber immernoch nicht wirklich sicher, wie ich das ganze angehe und vor allem, wie ich die Items mit allen Infos speichern soll.

Ich hoffe das Problem ist irgendwie verständlich und ihr könnt mir damit weiterhelfen.

 

[Avankziar]

Heißt das, dass du keine Ahnung hast, wie das gesamte umsetzten kannst, oder heißt das, dass du bei einem spezifischen Problem hängst?

 

[Addycted]

Heißt das, dass du keine Ahnung hast, wie das gesamte umsetzten kannst, oder heißt das, dass du bei einem spezifischen Problem hängst?

Das heißt, dass ich nicht weiß wie ich so viele einzelne Infos in der SQL speichern kann.
Ich hatte erst gedacht, vielleicht jedem Rucksack eine ID zu geben und dann dessen Slots in einer Tabelle zu speichern. Aber dann fehlen mir ja auch noch alle Infos zu den Items auf den Slots beispielsweise Verzauberungen oder die Beschreibung. Die Tabelle würde den Rahmen mMn. sprengen, deshalb suche ich nach einer alternative um es etwas leichter aber trotzdem im vollen Umfang zu speichern.

Also mein Problem ist ehrlichgesagt, dass ich nicht weiß, wie ich den ganzen Inhalt eines Inventars so klein und schlau wie möglich speichern soll. Denn ein Rucksack in Größe einer Doppelkiste voller Items, die alle nochmal mehrere Infos zu speichern haben wäre wahrscheinlich absolut unschlau gespeichert mit einer solchen...

Spoiler: ...Rahmensprengende Tabelle

RucksackID

Item1

Item1Verzauberung

Item1Name

Item1Lore

Item1Amount

sollte

reichen

zum

verständnis

 

[Avankziar]

Im EndEffekt brauchst du nur 3 Dinge.
Die Id, das Item an sich, und der Container des Items (Spricht das Inventar des BackPack).
Und so würde ich vor gehen.
Erstmal mache ich aus den drei Dingen eine CustomObject.
Die Id würde ich nur als Bezugspunkt nehmen, wenn ich schon das Item habe.
Dann würde ich das Item pre ReflectionUtils/Json in einen String wandeln. Das ist somit mein eigentlicher Suchwert für die mysql.
Und der angehangende Container setzte ich als Base64 um. Da kann man aber auch nehmen was man will^^.

Und im Endeffekt gehst du dann so vor, dass wenn das Inventar des Rucksacks aufgerufen werden soll, setzt du das Item per Reflection/Json in einen String um, mit dem du dann in der Mysql suchen kannst. Der wiederrum gibt dir das Base64 zurück und das setzt du dann wieder in den Ursprungszustand des Inventares zurück. Aka decodieren. Und dann öffnest du es einfach.

Ps.: Ist vielleicht nicht die beste/schönste variante, aber ich meine es würde funktionieren^^

 

[Addycted]

Ps.: Ist vielleicht nicht die beste/schönste variante, aber ich meine es würde funktionieren^^

Gut danke für die Info. Ich werde mich dazu mal belesen und schauen ob ich das ganze irgendwie hinbekomme.

 

[Ativendus]

Ich würde empfehlen, gerade wenn man mit Java angefangen hat, mit MongoDB anstatt MySQL zu arbeiten. Grob gesagt läuft MySQL über SQL Queries und MongoDB über Documente, in Java quasi Objekte und man muss nicht eine ganz neue "Sprache" lernen

 

[Addycted]

naja ich habe ja nicht gerade erst angefangen, sondern bin nur raus. Ich habe erst vor einigen Tagen wieder mit Spigot Programmierung angefangen und eigentlich auch mehr als ausreichende MySQL Kenntnisse, nur eben in einer anderen Programmiersprache und auch mit Bezug auf ein anderes Game.

Ich hatte nur tatsächlich noch nie vorher das Problem, dass ich so viele ineinander "verschachtelte" Infos speichern musste.
OOP habe ich tatsächlich auch kaum anwenden müssen, verstehe ich jedoch mittlerweile bzw. kann ich es in Java anwenden (einige Dinge sind ja immer etwas unterschiedlicher in den Sprachen, als andere).
Aber der Ratschlag ist trotzdem nicht schlecht, für Neulinge in Bezug auf Datenbanken.

 

[Feli490]

Ich würde dir tatsächlich empfehlen da komplett auf eine externe Datenspeicherung zu verzichten.

Guck dir mal die CustomItemTagContainer API von Spigot an mit dieser kannst du beliebige Daten in einem Item Speichern.
Damit kann man z.b. das Inventar in einer YML String speichern und diesen an das Item selber hängen. So sparst du dir komische Umwege über eine ID um auf eine Datenbank zuzugreifen. Auch hast du so nicht das Problem das, wenn der Rucksack an sich nicht (mehr) existiert, du keine Daten mehr in irgendeiner Datenbank rumfliegen hast.

Wenn du nicht von der Datenbank Idee abweichen möchtest, würde ich dir dennoch empfehlen die Rucksack ID mithilfe der CustomItemTag API zu speichern und du dann einfach die Items serialisiert als YML in die Datenbank speicherst. Spricht zwar mehr oder weniger gegen die 1. Normalform, sehe ich aber in diesem Zusammenhang als komplett unkritisch und als eine legitime Lösung an.

Wie genau du jetzt in die Datenbank Speicherst ist natürlich eine andere sache, du kannst einmal die Kompletten Informationen eines Rucksacks abspeichern:

rucksack_id	rucksack_yml_configuration
Beinhaltet die Rucksack-ID	Beinhaltet die kompletten Rucksack-Informationen. Also Slotanzahl und Items in den einzelnen slots.

Auch eine andere Möglichkeit wäre es diese Informationen auf 2 Tabellen aufzuteilen und dann die Informationen Kleinteiliger abzuspeichern:

rucksack_id	anzahl_slots
Beinhaltet die Rucksack-ID	Gibt die Anzahl der Slots an

rucksack_id	slot	item
Beinhaltet die Rucksack-ID	Beinhaltet den Slot in welchem sich das Item befindet	Beinhaltet das Serialisierte Item, z.B. in einer YML o.Ä.

Sind natürlich nur 2 mögliche Designs die mir auf die Schnelle eingefallen sind, würde aber sagen für einen Java/SQL Anfänger (soll nicht böse gemeint sein, wirkst aber noch relativ unerfahren in dieser Thematik) sind das sinnvolle strukturen.
Ich würde wahrscheinlich auch auf ein ähnliches Design wie das 2. zurückgreifen, da es tatsächlich irgendwann nicht mehr Sinnvoll/Verhältnismäßig ist das noch komplizierter zu machen.

Ich hoffe ich konnte dir ein wenig helfen

MfG,
Feli

 

[Ativendus]

@Feli490 vielleicht möchte er die Rucksäcke ja aber über mehrere Server verteilt benutzen, dann kommt nur eine Datenbank oder eine Verbindung zwischen den Servern in Frage

 

[Chrisliebär❤️]

@Feli490 vielleicht möchte er die Rucksäcke ja aber über mehrere Server verteilt benutzen, dann kommt nur eine Datenbank oder eine Verbindung zwischen den Servern in Frage

Dann muss er aber auch die Items irgendwie zwischen den Server übertragen und außerdem ist die Aussage nicht korrekt, das Inventar kann auch im Filesystem abgelegt werden oder sogar über BungeeCord synchronisiert werden. Da das Inventar sowieso einfach nur Blob ist, den man irgendwie aus dem Plugin raus und wieder reinstecken muss, ist es sowieso absolut egal, wo man das speichert. Datenbanken bringen da nur zusätzliche Komplexität ins Spiel (was z.B. wenn die Datenbank nicht erreichbar ist, etc.).

 

[Feli490]

@Feli490 vielleicht möchte er die Rucksäcke ja aber über mehrere Server verteilt benutzen, dann kommt nur eine Datenbank oder eine Verbindung zwischen den Servern in Frage

Wenn du sämtliche Informationen die für den Rucksack benötigt werden im Item selber speicherst (mein erster Vorschlag), dann kannst du überall wo du dieses Item hast (und das Plugin auf dem Server ist) den Rucksack verwenden.
Dann brauchst du keine Datenbank.
Wie ❤可愛いちゃん️❤ auch geschrieben hat bringt eine Datenbank Komplexität mit sich, denn eine funktionierende Datenbank-Implementierung ist nicht auch gleich eine Sinnvolle/Stabile. Wieder eine Abwägungssache von Aufwand/Nutzen/Vor-/Nachteile.

Mal abgesehen davon gibt es auch noch X andere Möglichkeiten das Problem ohne eine Datenbank zu lösen, ob diese sinnvoll(er) sind ist dann natürlich nochmal eine andere Sache, aber zur Übung aufjedenfall sinnvoll sich vielleicht mal mit anderen Lösungsversuchen auseinander zu setzen. Und dann evtl. deren Vor-/Nachteile gegeneinander aufwiegen.