yml-file als db nutzen

[LordKaktus]

Mag sein, dass die Frage ziehmlich blöd ist, aber ich stehe gerade auf dem Schlauch.
Ich möchte eine Yml-Datei als DB-File nutzen.
Mein Problem dabei ist, dass die Datei nicht wie die Conf nach dem Erstellen nurnoch ausgelsen werden soll, sondern zudem noch erweitert werden soll.

Spoiler: meh

public static boolean createarena(String ArenaName) throws IOException {
     YamlConfiguration c = new YamlConfiguration();
     if(c.contains(ArenaName)){
       return false;
     }
     c.set(ArenaName, true);
     c.save(new File(plugin.getDataFolder(), "arenas.yml"));
     return true;
  }

Ich möchte später weitere Arenen anlegen und als unterpunkt Locations ablegen. Aber so überschreibt er mir ja immer das vorhandene file mit einem neuen
So wie es aussieht muss ich wohl zuerst den content der vorhanden datei einlesen und dann zusammen mit den neuen werten abspeichern?
oder gibt es da einen unkomplizierteren weg?

 

[MiCrJonas]

YamlConfiguration c = YamlConfiguration.load(File);

 

[Chrisliebär❤️]

YML ist ne richtig blöde Idee für Datenbanken, da die "Datenbank" mit zunehmender Menge an Einträgen langsam wird. Solange wir hier von ein paar 10-50 Einträgen sprechen, die nur selten geändert werden, mag das okay gehen, aber wenn du regelmäßig Daten speicherst/löschsts/liest wirds zum Problem.

Hängt halt stark davon ab, was du wirklich machen willst.

 

[LordKaktus]

Naja Ich habe gerade erst mit Java bzw. Plugins angefangen. Flatfiles sind die einfachste Variante etwas abzuspeichern und da ich nicht sonderlich viele Dinge darin speichern möchte, ist es wohl auch die beste Variante. Zudem kann man die Flatfiles auch ohne aufwand einsehen und editieren, was einem am Anfang das Verständniss erleichtert

 

[LucaDev]

Ich würde dir MySQL oder sqlite empfehlen

 

[MiCrJonas]

YAML muss nicht unbedingt langsamer sein als MySQL. Wenn man beim Serverstart die Datei lädt, und erst beim Serverstop speichert, sollten auch große Dateien keine Probleme machen, denn wenn die Datei einmal als YamlConfiguration geladen ist, ist es egal, wie groß die Datei ist. Anders sieht es aus, wenn die Datei jedes mal neu als YamlConfiguration in den RAM geladen wird. Das Gleiche gilt aber auch für die Benutzung von MySQL.

 

[LucaDev]

Jein, aber des weiteren entstehen bei YAML Konfigurationen mehr Fehler bei gleichzeitigen Zugriffen auf die Datei

 

[GermanUbuntu]

ich empfehle dir auch MySQL oder ggf. MongoDB

 

[LucaDev]

ich empfehle dir auch MySQL oder ggf. MongoDB

Ich mag MongoDB nicht ich bin zu blöd noSQL zu verstehen

Ich empfehle SQLite wenn es in einer Datei sein soll oder memSQL wenn du viel und schnell arbeiten musst und Linux hast, aber das ist für Minecraft Server nicht nötig

 

[LordKaktus]

Das yaml file sieht im fertigzustand etwa so aus:

Arena1:
  Red:
    X:
    Y:
    Z:
    Yaw:
    Pitch:
  Blue:
    X:
    Y:
    Z:
    Yaw:
    Pitch:
  King:... 
  Lobby:...

bei spielstart werden die werte in eine variable geladen welche dann in einer for-schleife genutzt werden
Einen gleichzeitigen zugriff würde ich als sehr unwarscheinlich bis gar nie vorkommend sehen, dar genau parallel zum spielstart eine andere arena erstellt werden müsste

 

[|| xX [DEV][LP] Ms. DivaCraft Xx ||]

Da hier alles geklärt ist werde ich diesen Beitrag nun schließen. Es geht hier nicht um eine genaue Analyse welches Datenbank System das schnellste ist.

Meine bescheidene Meinung:

Spoiler

Ohne die genaue Implementation zu kennen, wird durch das Speichern der YamlConfiguration die Werte abgespeichert und die Datei editiert. [Die YamlConfig solle außerdem die Daten ebenfalls im Speicher ablegen.] Durch die immer wachsende Dateigröße ist natürlich das erneute einlesen der Config steigend ineffizienter, aber das macht die Lösung nicht schlechter. [Siehe auch @MiCrJonas Beitrag]

Wenn die Arenen sowieso im Speicher geladen bleiben ist diese Lösung ohne große Nachteile. Alternativ kann auch für jede Arena eine eigene Datei erstellt werden, sodass die Arenen entladen werden könnten.

Andere angebotene Datenbanken bieten hier nur kaum Vorteile, Relationen sind hier ebenfalls unwarscheinlich.