This project is read-only.

Underlying Storage

Jan 25, 2011 at 4:12 AM

The underlying storage system can be done in a multitude of ways.  What do I mean?  When a client logs on, they expect to be standing in the same place as they were when they logged off.  They also expect that their inventory still exists as well as the fact that if the server undergoes maintenance; all client data needs to be persistent.  So here are the ideas to get this accomplished.

  • PostgreSQL
  • MySQL
  • Oracle
  • DB2
  • Filesystem

So let's take a look at these, the first four are databases.  They already are designed against errors and many of them already have the HA capabilities through replication.  They are all pretty much the same and they'll all pretty much be the same (except support) since all we're using this for is the storage.  PostgreSQL does not have corporate support although it is not needed but it is free.  MySQL has many flaws with the data storage engines (including row locking versus table locking etc...) but it is free and support can be paid for.  Oracle is designed for large implementations; it is free to try but every expensive if you need to run it long term.  Support is definitely there.  DB2 I have no real information about but seems to be on-par with Oracle.  The good news about doing a database; it is simple to do data mining with.  I.E. finding where players mainly congregate; enemies that players kill often; messages etc...


Doing a plain filesystem is usually the quickest and dirtiest way to go.  The main thing with this is its free and essentially each character is stored in one file.  The big thing is that there is no easy redundancy except setting up an archive application and then copying it to another machine.  The good news is that it's free and always will be since you already own the filesystem.  The other bad part is that it's hard to data mine the direct files without writing separate applications or writing an entire query language to mine it.

Feb 1, 2011 at 12:24 AM

I guess I'll go ahead and start here.  My thoughts are on MySQL mainly because that is where the base of my knowledge about databases come in.  It provides us with a free solution to store user data and is still robust enough to actually run up to a couple hundred users at once.  My other thought is that if we code it properly, we can probably abstract this to the point where it doesn't matter.  I.E. Hey I need X information; and having an API that would be able to pull this data.  This would allow a migration from any database to any other database should the need arise.