[MUD-Dev] Re: DBMS in MU*'s

[J C Lawrence]

On Sun, 19 Jul 1998 14:29:26 +0200 
Asmodai <Jeroen> wrote:

> Well met all, I have been wondering, most MU*'s use ASCII-files as
> storage for the object database their MU* carries. 

Depending on your definition of "most", this is semi-true.  Cold and
others store binary byte-coded versions of their objects in their DB.
There are several other variations.

> As far as my basic knowledge about databases goes this could be
> enhanced and maybe even sped up by using a relational/referential or
> Object Orientated DBMS alongside or in the MU*.

This is really dependant on the character of your DB accesses, and in
particular how much if at all your object heirarchy will morph during
the server runtime.  In my case the entire object heriarchy may be
re-written during the game runtime (there is no pre-defined
structure).  Others use a single pre-fixed heirarchy which can only be
linearly extended during runtime if at all, as well as several grades
inbetween.

Attempting to translate my model into, say, an SQL DB (as I briefly
attempted), poses problems.  The inter-object relationships which
(presumably) require indexes are dynamic and defined by the
user-written contents and definitions of the objects.  As such I can't
pre-define the record structure in a manner that maps directly to the
object heirarchy.  

I can instead chose a simple structural model, say with one table for
the object ID's, another table for the objectID->method/attribute
names/definitions, another table for the verb bindings, another for
the inheritance parentage etc.  However this imposes a severe
performance penalty as any object access now requires traversing
multiple indexes to retrieve any single portion of an object.  Even
worse are the number of traversals needed to retrieve an entire
object.  Index traversals quickly became the limiting factor,
especially for internally complex objects.

But, even if I do this it gains me nothing.  The mere fact of the DQL
DB doesn't particularly allow me to do intelligent queries of the DB
as there is no intelligence about the object heirarchy built into the
DB representationm, so instead I have to write a custom filter which
sits atop the DB and attempts to impart intelligence to the
presenation of the DB contents and its heirarchy.  Why bother?  I can
use a simple ISAM DB, lose all the index traverses, drop my complexity
an order of magnitude, and still use the same filter to impart the
same sense of intelligence.

If your server does not support runtime morphing then, as discussed
here earlier (see archives), you can efficiently get away with a
standard RDBMS.  That said most current designs access their objects
only thru object ID and comparitively rarely thru relational filters
(this is a design-time consideration -- you can design and implement a
server to do relational accesses, its just that nobody has).  In such
simple cases (essentially a degraded RDBMS model with only one index)
a standard ISAM approach works well and is in essence identical to the
RDBMS with one index.

OO DB's?  Yes, potentially these give the greatest promise.  The
problem is that there are no (known) OODB's which support runtime
morphism with the result that attempting to wedge-fit them to the job
is an excercise in frustration.  I presume that they could be used for
runtime-static games fairly well, but have not checked.

> Are there people on this list that have actually tried this? Either
> the relational/referntial or the OO DBMS.

Semi.  Lambert has also done some work in the area, as well as having
a professional familiarity with current DB products.

> I apologize if this has allready been covered in earlier posts, I am
> in the prospect in reading all the backposts, so if this was already
> discussed in previous posts, please direct me to the year the posts
> were made in so I can scavange for them =)

Have a look at the thread rooted at:

  http://www.kanga.nu/~petidomo/lists/mud-dev/1998Q3/msg00013.html

It doesn't provide a whole lot, but if you keyword search off there
you should find the rest.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...