ArrayList<String> als Blob in Datenbank speichern

    Hi red51 ,


    wird in der neuen API auch das Unterstütz?


    Das speichert eine String-Liste als Blob in eine Datenbank.


    Oder gibt es da eine bessere Lösung? :thinking:

    Fragen bzgl. SQL bzw. der Datenbankanbindung sind leider noch etwas schwierig zu beantworten :saint: In dem Bereich gibts leider noch ein paar Fragezeichen... denn in der neuen Version haben wir uns für die SQLite Anbindung einen eigenen Wrapper geschrieben, dieser bietet aber bei weitem nicht den Funktionsumfang von JDBC bzw. des java.sql Packages (da war das meiste davon nicht brauchen).


    Wir haben da momentan zwei Optionen: Entweder wir bieten weiterhin die Xerial JDBC Lib für die API an (das ist die, die auch die Java Version von RW verwendet) - dann ist der volle JDBC-Funktionsumfang gegeben, allerdings können wir keinen Zugriff mehr auf die Weltdatenbank(en) geben. Oder wir bieten eine eigene, teilweise Implementation von JDBC an, was aber viel Aufwand bedeutet... mal sehen... :silenced:


    In deinem konkreten Beispiel allerdings sehe ich keinen Bedarf, mit einem Blob bzw. SerialBlob zu arbeiten. Im Grunde sind diese Objekte lediglich eine Abstraktion für ein byte[] (welches auch so direkt in der Datenbank gespeichert werden kann, ohne, dass man den Umweg über das SerialBlob Objekt gehen müsste). Die eigentliche Serialisierung der ArrayList nimmt in diesem Fall der "ObjectOutputStream" vor, bzw. konkret der "writeObject()" Aufruf - und da das zum Standard-Java-Repertoire gehört, wirst du das auf jeden Fall auch in der neuen Version nutzen können ;)

    Hi, sorry for replying in English - it' much easier for me ;)


    Just opening up a friendly dialogue; why did you choose to use a Blob (Binary Large Object) ?


    A statement would be better saved in a database in a collection of tables called something like `Statement`, `Statement_Details`, and any other tables needed for additional data depending on what you want to store.


    With this sort of schema your SQL statements can gather all sorts of information which would be unavailable to you if you use a Blob.


    For example, you could run a statement to pull up all Statement_Details that have an Amount greater than a specific number (Let's say 1 million for example).


    Sudo code: SELECT * FROM Statment_Details WHERE `Amount` > 1000000 ORDER BY `Amount` ASC


    This would find all transactions over 1 million and then list them in ascending order. Creating information out of data.

    red51 : Danke für deine Antwort. Wie kann man ein byte[] in eine Datenbank speichern?


    yahwho : Thank you, too, for your answer. English is not a problem for me. ;)

    I know that you can save each statement individually in the database, including details.


    The only thing I have to worry about is the amount that is then written to the database. So that there is not so much communication with the database, everything is saved in variables when the server is started. All calculations are then made there. When a period of time has passed, or a player leaves the server, or the server shuts down, the database will be updated with the variables.

    It's just easier to overwrite a blob than it is to go through a list.


    Let's get back to the crowd:


    Let's assume there are around 30 people playing on the server. Every time a player wants to deposit or withdraw something from the bank, a statement is created so that one can later see what happened at the bank with one command. It can happen that a player is offline. This player offers something for sale on the server. He connected his shop to the bank. Later, when we are back online, the player wants to know if he has sold something. He can now look up this in the statement. This player doesn't just sell one object, but maybe 30. And of these 30 objects, he made stacks of 10, which are all sold individually. 30 x 10 = 300. This means that 300 bank transactions can take place in this shop.


    Unfortunately it's not just one player on the server, but 30. Anyone from then could open a shop.

    Now if everyone sells 300 items, that's: 300 x 30 = 9,000 bank transactions.

    So that's 9,000 statements.


    But now there is the greatest of all:

    What if everyone has now paid not with cash but with the bank?


    Then I have to double everything again, there is a statement for paying out and a statement for paying in.


    That is then 18,000 statements. etc. :dizzy:

    And that, if things go wrong, everything could happen in one day.


    That's why I chose Blob. I can tell an ArrayList that it should only display the last 50 statements.

    I don't have to compare what is already in the list and what is new with the list in the database.

    It is simply overwritten.

    I've been thinking about this. I understand your reasoning for a recent "buffer" (for want of a better word) to only store the most recent 50 transactions per player.


    You could use UPDATE as opposed to INSERT statements. Assign 50 rows for each user in a Statement table and then UPDATE these rows.


    Anyways just ideas. If the code is already written and Blobs are working for you - if it ain't broken don't fix it. :D

    Quote from Sandboxgamer

    red51 : Danke für deine Antwort. Wie kann man ein byte[] in eine Datenbank speichern?

    Wenn du zB ein PreparedStatement verwendest, kannst du einfach via setBytes() ein byte[] übergeben. Ein Blob ist im Grunde nichts anderes als eine Hülle um ein byte[] ;) So könnte das zB in der PluginAPI aussehen (angenommen die Column "data" wäre hier in der Datenbank vom Typ BLOB):

    Java
    byte[] bytes = ...; // <- Dein byte-Array mit irgendwelchen Daten

    

    Connection con = db.getConnection();

    try(PreparedStatement stmt = con.prepareStatement("INSERT INTO `MyTable` (`id`, `data`) VALUES (?, ?);")){

        stmt.setInt(1, 42);

        stmt.setBytes(2, bytes);

        stmt.executeUpdate();

    }


    Wenn du hingegen Daten aus einer Tabelle auslesen möchtest, bietet ein ResultSet entsprechend auch eine getBytes() Funktion.

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login