Sign in to follow this  
stormwarestudios

Data access

Recommended Posts

Hi all, In developing the table access for my game, I came across a dilemma, one which I need to research more. The application in question is a multiplayer game-server, which is written in C++, and uses MySQL as a database back-end for record storage. I have theorized a number of different methods of handling the data in the tables: Method 1: prefer database - all data is accessed from database at run-time - when data needs to be accessed, SQL queries are made to obtain records. - when data needs to be modified, SQL queries are made to change records. Pros: - data is very portable (e.g. database server mirrors can be maintained, in the event of database server going offline) - simplest method of maintaining records (e.g. records are accessed directly, rather than saved at intervals) - no "save time" required, since records are updated realtime, hence no down-time Cons: - slowest method of data access, since record access implies network latency comes into play Method 2: prefer system memory (use direct-access C++ memory pointers) - at load-time, all data is loaded into memory (e.g. STL::deque); table linkage is made via pointers - at save-time, table linkage is de-referenced, and database tables are stored using SQL queries. Pros: - fastest method of run-time data access Cons: - most complicated method of saving and loading, since data must be (de)referenced into tables at load/save time - middle-ground 'down time' between server saves due to necessary pointer dereferencing Method 3: prefer system memory (use table indices/STL::map references) - all data is loaded from db tables into memory at run-time, into memory/STL::map tables, using unique record IDs as indices - during run-time, data is accessed directly via table/STL::map indices - during save-time, tables are stored using SQL queries Pros: - simpler implementation than method 2 but more difficult than 1 - faster execution than 1 but slower than 2 Cons: - slow data access due to STL::map indicing My question is, should I favor: - ease of implementation (Method 1)? - run-time execution speed (Method 2)? - a middle-ground of both (Method 3)? Typically common programming mindsets are "keep it simple, stupid", "make it work, then make it work fast", or "if at first you don't succeed, refactor", but because the differences in design vary greatly enough, if I choose a method whose performance or maintainability are horrible, then I am losing precious time reimplementing a different method. Thanks for any input.

Share this post


Link to post
Share on other sites
Do you need transactions? What are your roll-back requirements?

If you decide to simply keep all your data in memory, and use your database as a back-up system, then you might consider simply writing binary data to a flat file. Easier, simpler, faster :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this