[MUD-Dev] Database back ends

[Kevin Littlejohn]

>>> Greg Underwood wrote
> 
> 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.
> 
> 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.

Funny story:  In tinkering with exactly this, I've found it _is_ possible to
write cacheing systems that severely slow things down ;)

Seriously, most modern db systems are designed to deal with _lots_ of requests
per second - your average mud shouldn't stress your average db.  However,
there's an added few milliseconds on every request which has to be dealt
with.  In the end, cacheing is probably a good idea somewhere along the line,
depending on your design - if you're holding everything in db for persistance.

If you're just using the db as a load/save store area, then most of this
is irrelevant - you'll not stress the db, go for your life ;)

Incidentally, 5000 players online at once would suggest to me that a db is
a good idea - if for nothing else than for it's backup and replication
abilities.

> 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?

Because usually the table structure has no bearing on anything in-game?

My tables are in form:

CREATE TABLE attributes (
  id int(11) DEFAULT '0' NOT NULL,
  name varchar(32) DEFAULT '' NOT NULL,
  last_update timestamp(14),
  value text,
  value_type varchar(20) DEFAULT 'string' NOT NULL,
  value_exist char(1) DEFAULT 'Y' NOT NULL,
  PRIMARY KEY (id,name)
);

(MySQL create statement).  id is object id that owns this attribute,
name is name of attribute, value is value of attribute, value_type indicates
how to de-munge the value I've stored to get the right thing (text fields
in MySQL act close enough to blobs, so in essence I store a text representation
of any value, and know how to convert it back).  last_update isn't actually
used atm.  value_exist is part of my wierd inheritance scheme.

Modifying this structure would be fairly pointless ;)

There are some funky things you can do quickly in SQL, tho - give someone
a spell that tells them where the nearest x is, and finding the locations
of all the x's is at least considerably faster.  (Then you've got to figure
out proximity, but that's another story ;).  Global spells - something that
adds a temporary +1 to all swords in the world - are easier via SQL ;)

Oh, in inheritance world, changing all descendants of object x to be
descendants of object y is easier in SQL, too.

This stuff has been discussed before in the archives - worth doing a quick
browse through them.  Search for 'MySQL' is probably the quickest and
easiest way to find info ;)

KevinL



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