[MUD-Dev] Re: Databases

[T. Alexander Popiel]

>Message-ID: <01BF5F7A.CD766340.charles.hughes at bigfoot.com>
>From: Charles Hughes <charles.hughes at bigfoot.com>
>Date: Sat, 15 Jan 2000 17:06:02 -0500

>At the risk of being slapped by a mackerel, who here really thinks they
>can do a better database design than those afforded by the likes of the
>free or commercial databases?  [I'll ask those here who've actually
>worked on these databases not to chime in. :)]

For the limited problem set of a MUD world, yes, I think that I can
design a better database than one of the free or commercial ones.
There is a simple reason for this: commercial databases want to
pretend that you are the only person using the database at this time,
while a MUD wants to glorify the fact that there's a lot of other
people there that you are (forced into?) interacting with.

Getting a little more specific, the commercial databases (and
generally the free ones that I've seen, too) are optimized for
relatively few large transactions where there is relatively little
overlap and contention, frequently with rollback as the contention
handling mechanism.  A MUD world has extremely small transactions
(open/close of a door, get the contents list of a room) with
contention being extremely frequent, and rollback is a very
unsatisfying contention handling mechanism.

There's also (for the user-programmable MUDs at least) an issue
of ease-of-use, since many of the people writing code for the
MUD will _not_ be experienced coders who think through all the
special cases.  In commercial databases (at least the ones that
I've seen), you have to make at least token acknowledgement that
some operation may fail, either by explicitly asserting a lock
to prevent contention, or by setting up a retry loop to handle
rollback, or by breaking up your transactions into less contentious
pieces.  These things _are not obvious_ to the novice coder, and
thus lead to unsafe code being written, and failures that utterly
confuse the users.  Even worse, when the novice coders learn of
some of this, they are likely to try writing retry loops without
any limiting factors (or other similar fax pass), turning a simple
failure or deadlock into CPU-eating starvation.

A good MUD database will make the common operations easy, and
will protect the user from the obvious mistakes.  This often
takes the form of making player and mob movement atomic, giving
easy access to contents lists as a single unit, etc.  The exact
operations that need to be protected will vary greatly based on
the physics of your MUD world (the presence or lack of long-range
effects will greatly effect whether or not you need global
synchronization of the database, for instance).  Because of this
variability, I strongly believe that there is no one right solution
to the MUD database design problem, and moreover that the extant
commercial and free databases don't come even close to providing
what most MUDs need.

- Alex



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