ID:2087836
 
So... I've been thinking about using something else besides savefiles in my game... Then, i started to look for information about the ups and downs of each option (Savefiles, MySQL and SQLite)... But then i didn't find much about this.
Then, what i want to know from you guys is: What are the pros and cons of each option? Is it really worth to use MySQL or SQLite instead of savefiles? Do it really has a significant performance change?


Thanks a lot! :D
Use both. Don't use SQL in lieu of savefiles.
Anyone? ;-;
From experience, normal savefiles work just fine, just don't call Read() or Write() directly and the thousand other tips on the topic.

Actually, Dream Tutor: The Pitfalls of Savefiles by Lummox covers that topic, you can give it a read.

Savefiles work fine most of the time, like Rotem stated.

However, if you're storing lots of information that you'd like to run queries on you might consider SQLite. Such as logging information that you might want to display later. Possibly sorting by who sent the message, date ranges, etc.

MySQL is great if you want the information accessed from external sources. SQLite would be stored locally. In this instance wherever your host files are located. Where as with MySQL you can connect to that database remotely. So, your game can access that information, along with your website and other external applications.
Performanse-wise, how do we compare Savefiles vs MySQL vs SQLite? It is about the same... Right?
I'm not sure about MySQL vs SQLite.

However, I believe MySQL/SQLite are faster than Savefiles.

EDIT: The only thing with MySQL is you have to factor in ping and response times if the database isn't on the same machine you're hosting your project from.
In response to PatrickBR
You seem to be under some sort of fear from the performance of savefiles, I assure you, it's completely fine and you have nothing to fear.

There's few very very simple things you shouldn't do when using savefiles, if those basic things are followed you'll be in the clear.

If you want to do player saves, use savefiles. I don't really see any reason for you to worry about SQL.

MySQL is useful if you want to maintain a central database, but the downside is that the login credentials have to be shared, so you may want to find another way to centralize your info. There's also a known issue that the MySQL library we use isn't capable of non-blocking operations, which means if it ends up getting hung up on a network delay or something, your whole server can freeze temporarily while waiting for a response.

SQLite a better tool for general single-server database use, as it's built directly into BYOND and doesn't require any .dll/.so files. It's also not going to use the network, since it's on the host machine.

Savefiles are best for most practical saving purposes, since BYOND can handle a lot more data types directly.

With either of the database options, the main reason to use them would be if you want to correlate a lot of data and run queries on it. For instance, if you store player scores and levels in a db, you can grab the top 10 at any time. If it's just about saving things, savefiles are probably your better bet. A big enough game may want to use both: savefiles for saving players, a database for storing other info.
MySQL is great for multiple servers sharing the same "saves" or data .. I don't see why no one has mentioned this..

It's a shame it's blocking the network though, I believe SS13 had an issue with this, not sure if they've found a way around it or just moved onto an alternative.
You can use mysql proxy and mysql replication to solve those issues.

Selects would come from a local database, so no network delay, insert/update/delete goes to a remote database in a way that it doesn't wait for the insert to finish, then you just have to avoid trying to select data you recently inserted as it might not be replicated from the remote database to the local databases.

Another thing is avoiding the paradigm of select, if nothing, insert, else, update if you don't need the info that you select, as there is a way to merge an insert and update query so that if the row doesn't exist, you insert, else you update it, but you do this in one query and avoid the query overhead (INSERT blah ON DUPLICATE KEY UPDATE blah=blah) (and on that note, you can insert multiple rows in one query, also allowing you to save on query overhead)

Also, index index index index. if you WHERE by a column, you should always have an sql index on that column to make resolving those WHERE clauses much much faster.

Basically at ss13 we just focused on keeping this blocking overhead from ever mattering.