When to consider a SQL database over script-side data storage?

Posted by Sickent on Fri 01 Jan 2016 07:28 PM — 2 posts, 12,454 views.

USA #0
tl;dr When do you consider using a SQL database over writing all the information into a lua script/plugin, if you're not worried about storage functionality over continuing sessions of play?




I want to write a map plugin for myself. Because a lot of information can be involved in a client-side mapper, I don't know if starting a SQL database is better for performance than just continuing to write tables in a lua script/plugins.

One of the reasons I stick with MUSH is performance; lua and scripts are processed ridiculously fast, especially when compared to the Z/CMud I came from. Because of those past horrid experiences, stability and performance are now my first concerns with client.

I realize that when you use a script or plugin in MUSH, it loads the entire file into memory and works it from there. When you work with SQL, or any other database I imagine, only requested information is loaded into memory, as the rest of the database is kept on the hard disk.

So this is my comp.

http://pcpartpicker.com/p/wJmhwP

There a reason I can't just write everything I want to a script/plugin, or multiple plugins? What thresholds in data, field size, or whatever are needed to make you start considering writing and accessing your information to SQL database? I have like 16gb of fairly fast memory, and I can't imagine even loading the entire world of a game in a go is going to be larger than, say 50mg of text.

Thank you for your help.
Australia Forum Administrator #1
For large databases I would use SQLite3. That was used by me in writing the mapper for Aardwolf and Achaea, and it loads room information very quickly. (I cached room data in a table once loaded to speed things up a bit).

The advantage of SQL is:

  • It is designed to be fault-tolerant, so even a client or PC crash should not lose any data (although I would make periodic backups).
  • You don't have to load everything into memory (and parse it) initially, which makes start-up quicker.
  • Since updates are done on-the-fly it isn't slow to save changes (like it would be to write a large state file).
  • You can always read the database offline for debugging or other purposes.
  • The same database can be shared easily between multiple worlds (eg. different characters on the same MUD) which isn't as easy with a state file.