Replacing RM database with Sqlite database

[Tsukihime]

RM's current database is basically a series of Marshal serialized files.


Sqlite stores its database in a file as well. Works out of the box. Much better than all the suggestions/requests for MySQL support cause then I'd need to download MySQL and set it up. Why? Not going to play your game.


There is much more support for sqlite than ruby's binary marshal format.


Can we replace RM's database with sqlite database?


For example, when you playtest your game, it will create/update the sqlite database.


Some people don't like File I/O, so when the is game is loaded, it will create an internal database of arrays (like it does now) from the sqlite database.


The purpose of the sqlite database, in this case, would be to simply store data, rather than being used for queries.


However, it becomes much easier for developers to create external tools, since they don't need to find a way to read/write binary ruby marshal objects.

 

[Dr.Yami]

I would prefer JSON or YAML (JSON is much lighter though)

 

[Tsukihime]

A database wrapper could provide a uniform interface that allows you to choose between various input formats, which would also provide more flexibility. For example, you can write a simple webpage that let's you set up some stuff, and since javascript supports JSON nicely it would be easy to export data.

 

[jamespedid]

I wouldn't see why not. Look up the SQLite3 gem. Be careful though, because this gem can be finicky when installing on windows machines. 

 

[Tsukihime]

I installed that gem but it looks like it looks like it requires native extensions to run, which RM doesn't allow.


Then again, I'm not sure if that's an absolute requirement.

 

[jamespedid]

It unfortunately does. It's just a wrapper on C bindings to SQLite3. There's portability issues that result in it as well.

A question that may need to be asked is: why would you want a relational database at all if all you're aiming for is data storage? The advantage to using such a system is the queries itself. Otherwise, you're better off persisting data to files. While it doesn't need to be serialized ruby objects, you can still persist data in many different ways, binary or text, that can also be edited by external programs. Two formats that were pointed out are JSON and YAML.

I think what you might be doing is confusing the "database wrapper" with what might normally be called a "model". A model is a way of representing data, storing and retrieving data, and specifying relations on models. A database is one way of implementing a model, but it isn't the only way. In Ruby on Rails, for example, a great deal of work was done to separate the model from the database using the model (this is the split between ActiveModel and ActiveRecord. ActiveModel is responsible for the relationships, properties, etc, of data where ActiveRecord is responsible from translating to and from SQL from this model relationship). ActiveRecord is one example of an adapter that can be applied to the models provided by ActiveModel in order to persist data; ActiveModel here would be representative of the common API that you're referring to.

 

[Tsukihime]

What I want is to be able to extend or replace the RM database for other, possibly non-ruby tools, to use, since ruby binary serialization is not particularly flexible for other tools.


Users shouldn't have to install anything extra in order to use it either, which is not the case with more complex things like mysql databases which also get requested from time to time also for the purpose of data storage.


Any format with a lot of tools available to create/modify would be good enough.


But you're right, if I were to stick with the existing code (ie: just loading it into the game and then never touching the data files again), then any sort of data storage format is suitable.

 

[BigEd781]

This seems like massive overkill to me.


As you said, it would be incredibly silly to actually query a database at runtime for game information. So, you want to use a database to store serialized data for one time retrieval. I don't see how that is any different than what RM currently does (storing serialized Ruby objects to disk).


If you want to support saving playtests and whatnot then you can simply modify the default scripts to do so. What other type of data would you like to store that couldn't simply be written to and read from disk? A database is complicated because it is meant to solve complicated problems. You're suggesting to use a database to store flat files which makes no sense to me.

 

[TroyZ]

yeah it's a good idea to replace the RM's default database with other databases such as MySQL, it'll greatly improve the developer because they can also work outside of RM only to edit the RM's database. but, does ruby has the functions to use/read anything outside it's own databases?

but i also think whether it'll cause any perfomance issues with RM when RM don't use it's own database

 

[Tsukihime]

"Database" would probably be a misleading term, since the idea is simply an alternative form of file storage (as opposed to making queries or anything that comes with database systems).


There are many libraries available for parsing JSON, XML, YAML, etc, of which some probably are pure-ruby implementations.


It is really only necessary to able to open and read data, because once you read in the data, you never need to use it anymore.

 

[TroyZ]

"Database" would probably be a misleading term, since the idea is simply an alternative form of file storage (as opposed to making queries or anything that comes with database systems).

so "database" in RM just means of "the form of file storage". RM "database" only consists of variables of array/hash and the data inside it, only that. we can't use the basic and general database functions in RM "database", such as INSERT, DELETE functions in it.

at the end, it'll just back to the developer itself whether they need to change the "database" itself into another database, hmm RM only used the database just for opening and reading the data, the rest itself never changed directly into the database (it's rarely to found the $data_ changing in the middle of the game, they just changing the $game_ data inside it, so changing the "database" i thought will be more useless unless the database itself are dynamic and can be parsed and changed through the entire game so we don't use the $game_ data again xixixixixixixi )

 

[Tsukihime]

Even if the database is dynamic, you wouldn't be modifying the data files that come with the game (otherwise, how do you start a new game?)


Plus, most of the CRUD methods that you need can be easily done without needing some specialized database functions.


Since the database is stored in arrays,


Creating is just pushing things into an array


Reading is just array indexing


Updating is just grabbing a reference and changing its attributes


Deleting is just `delete_at`, or `delete`


I can't see any use of queries for most tasks you would do in RM scripting.


I think if someone had to choose between looping over an array of objects, and figuring out how to write a SQL statement or other forms of querying...they'd probably just go with looping it themselves.