Sign in to follow this  

MMORPG Database Suggestions...

This topic is 4774 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If anyone has any suggestions on a database I could use for a mmorpg style game it would be a great help... If possible I would like to use DAO without MFC, but if there are other options availible they could work too (completely free of course) I do not plan to have an open source game for security through obscurity reasons. Thanks in advance.

Share this post


Link to post
Share on other sites
DAO why, is there any reason for choosing DAO? What about ADO or direct ODBC calls, if you want some code examples i'll post some up, i'm a business software developer (payroll & hr) by day so use mySQL, SQL Server and ORACLE db's on a regular basis.

Share this post


Link to post
Share on other sites
I've just used it before when programming an small scale mmorpg in visual basic... but sure code examples would be appreciated. :) The main thing i'm worried about is data access time, some data remains in memory while other data is loaded and stored back into the database (i.e. player logs on and the player data structure is loaded; the player logs off and the player data structure is stored)

Share this post


Link to post
Share on other sites
I'm not so sure of the necessity of a relational DB for a MMORPG ... could someone explain to me why it is needed?

And I am not talking about persistant data storage in general, but it seems like alot of hassle for a non-transaction based system. I mean, a MMORPG is pretty much a large physics simulation, not some goofy merchant website.

Share this post


Link to post
Share on other sites
I'd suggest Microsoft SQL Server. Oracle works too, but unless you have millions of dollars, then you're gonna want SQL server. I don't know anything about mysql except that it doesn't support stored procedures; you're gonna want those.

Share this post


Link to post
Share on other sites
Quote:
Original post by The Reindeer Effect
I'm not so sure of the necessity of a relational DB for a MMORPG ... could someone explain to me why it is needed?

And I am not talking about persistant data storage in general, but it seems like alot of hassle for a non-transaction based system. I mean, a MMORPG is pretty much a large physics simulation, not some goofy merchant website.


SQL servers are fast, reliable, and available.

I think you vastly underestimate the amount of data storage and retrieval necessary for an MMORPG. MMORPGs are persistent. To maintain the persistent world you need persistent storage. What better way to achieve persistant, real-time storage than an ordb?

[Edited by - smr on November 15, 2004 11:06:55 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by The Reindeer Effect
I'm not so sure of the necessity of a relational DB for a MMORPG ... could someone explain to me why it is needed?

And I am not talking about persistant data storage in general, but it seems like alot of hassle for a non-transaction based system. I mean, a MMORPG is pretty much a large physics simulation, not some goofy merchant website.


Lets say my player / account class is 100 bytes in length. Now lets say there are 10000 accounts, thats nearly a meg of data, of which only 90% is needed at one time. This data isn't needed until a player attempts to log on, so why waste that precious memory. Databases also make backing up the world a breeze.

Share this post


Link to post
Share on other sites
i'm going to recommend MySQL. from what i hear, it is just as fast or faster then any commercial database. and its free! (i just started using this a few days ago though - i may be wrong). you can't beat that.

also, whoever said MySQL can't do stored procedures is wrong. they are definetly possible with MySQL.

im working on a small scale persistant online RPG, and it was very easy to set up the MySQL server, pretty much just as easy as installing any program. setting up the library to work was a little bit of a pain, but i eventually got it to build. i use MySQL++ which is a simple wrapper around the MySQL C API, which basically makes dealing with the database as simple as dealing with a STL container. for example, heres a quick program i just wrote for testing purposes. it adds a new account to my account table.


#include "util.h"

#include <mysql++.h>

#include <iostream>
#include <iomanip>

#pragma comment(lib,"libmysql.lib")
#pragma comment(lib,"mysql++.lib")
#pragma comment(lib,"wsock32.lib")

using namespace std;

int main(int argc, char *argv[])
{
mysqlpp::Connection con("ftadb","127.0.0.1","root","notmyrealpassword",3306,1);

mysqlpp::Query query = con.query();

query << "INSERT INTO T_AC_ACCOUNTS (username, password) VALUES ('somenewuser','somepass')";

mysqlpp::Result res = query.store();

return 0;
}




pretty simple, no?

Share this post


Link to post
Share on other sites
Quote:
Original post by graveyard filla
also, whoever said MySQL can't do stored procedures is wrong. they are definetly possible with MySQL.


I stand corrected. When did they get around to adding sp support?

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
I stand corrected. When did they get around to adding sp support?


Version 5.0, which is pretty new.

I would also recommend mySql. It's easy to set up, has excellent documentation (almost unheard of in free software), and works as advertised.

Share this post


Link to post
Share on other sites
My thinking would be:

1. Use a SQL-based database with object-oriented wrappers and/or code generation.
2. Save binary data using a key/value file database using something like BDB
3. Create your own mad file format.

Stored procedures don't really sound relevant. Let's see what we're actually wanting:

- Data will be loaded at server startup
- Data are likely to be kept entirely in RAM during normal running
- Modified data will be periodically flushed out back to disc in case the server process crashes.
- Modified data will be saved if an administrative server shutdown is done
- Code updates happen from time to time, necessitating a server shutdown, possible database structure modification, and starting up a new server with modified code

Stored procedures won't be relevant (unless you design the startup / shutdown / checkpoint routines using them), as you won't want to keep any logic in the database. By *any* logic, I mean you won't even want to use WHERE clauses in selects most of the time probably.

So because it's essentially a bit bucket capable of load/save operations, SQL is overkill. But it has some useful properties:

- Reporting can be done using third party tools
- Manual tweaks are easier (Example: Some cheating method is discovered and you want to remove certain elements en-masse, during a server shutdown)
- Structural changes are easier: Adding / removing columns doesn't trash existing data.

The last one is quite important.

I'm not planning to write a MMORPG (unlike most people on here apparenly), but if I was I'd probably go with appproach (1) and try to find some way of using an automatic object persistence layer into a RDBMS.

Seeing as you won't even use most features of the RDBMS (No joins, fancy where clauses, procedures etc), its features are mostly irrelevant. Seeing as you won't be doing very many queries, performance is mostly irrelevant (will mostly affect startup time). So just use whatever's easiest.

Mark

Share this post


Link to post
Share on other sites
I'd say use postgresql.. allegedly "the most advanced open source database system in the world". It has more features than mysql and it's also free, but on the down side it may be slightly slower (i haven't made any comparisions myself so i can't say). Of course it depends on whether or not you need any of the features that mysql doesn't have. Last I heard mysql doesn't support subqueries which seems pretty shoddy. But still they are adding new features all the time so you never know... Anyways mysql vs postresql is one of those age old arguements that never seems to go away.

Share this post


Link to post
Share on other sites
Yes of course, of the open source RDBMSs, if you want features, use Postgres, if you want performance, use MySQL.

But as I already pointed out, I'm not sure this application requires either.

Mark

Share this post


Link to post
Share on other sites
Actually SQL DB's are quite useful for MMP's. Not so much for basic character data but for community stuff like friends lists, ignore lists, some aspects of chat channel management, etc.

Full-fledged transtions with rollback is also nice for item trades (to help avoid the common causes of item dup bugs).

Share this post


Link to post
Share on other sites
But I can't see why you'd want to write your game server tightly coupled with the DB server - I mean, using it for every transaction.

I would think that for item trades etc, the important thing was to write the game server correctly, and people won't be able to duplicate items. It should happen atomically

Basically, I would not be keen on the idea of using the DB server as part of my application - I'd prefer to keep it all in RAM and handle things myself, with load/save functions.

It will decouple things from the DB, improve performance and make the code simpler - the last one being the important one.

Mark

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
I'm not planning to write a MMORPG (unlike most people on here apparenly), but if I was I'd probably go with appproach (1) and try to find some way of using an automatic object persistence layer into a RDBMS.


This is more or less my approach.

Quote:

Seeing as you won't even use most features of the RDBMS (No joins, fancy where clauses, procedures etc), its features are mostly irrelevant. Seeing as you won't be doing very many queries, performance is mostly irrelevant (will mostly affect startup time). So just use whatever's easiest.


My experience has been a little different. Joins and where clauses are major reasons that using an RDBMS is crucial to my server. Game objects are highly extensible at runtime, so it made sense to maintain object attributes in a related table. That way a script could assign a new property to an object and save it to the database without worrying about the table structure.

Share this post


Link to post
Share on other sites
Edit: I should have read the thread in its entirety. Markr made exactly the point that I was trying to make initially. You need to look at your needs and plot a course of action based upon THEM. Don't just assume that you need xx, yy, and zz to have a successful system.

Share this post


Link to post
Share on other sites

This topic is 4774 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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