[MUD-Dev] Database back ends

[Greg Underwood]

dwacks at saleslogix.com writes:

> My question is: In general how do you feel about using a DB back end and
> what problems do you see with this.


While I've not actaully implemented a Commercial Off The Shelf (COTS) DB as
a back end, I've toyed with it.  The major concern that I had was
performance.  Where do you draw the line between what you keep in the DB
and what you keep in local memory?  Putting everything in the DB requires
that all actions within the game use SQL to actually do anything. 
Depending on the target size of your MUD this may work out ok, or may put
too much strain on the SQL interpreter.  I think the first thing you'll
want to do is determine the scope of the project (IE: how many simultaneous
player connections, how much DB access per player?) and then do some
performance testing on the various DB back ends.

Basically, as with anything in computers, it's a set of trade-offs.  Do you
want flexability and easy crash recovery/less crashes?  Put more in the DB.
 Do you want to be able to run 5000 players online at once?  Methinks
you'll need something more custom-built.

I've got a friend who works for a commercial game company, doing basically
what you want, but with Oracle.  I'll see if he's willing/able to comment
on any of the troubles he ran in to.

A fascinating thought I had a while ago was that, well, since the data
structures by and large determine the way the game works, wouldn't it be
neet to have spells that could actually alter the structure of the
database?  I mean, SQL commands can let you do things like add and drop
tables, fields etc.  Why limit the scope of the spells to simply altering
values within the tables?

-Greg



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev