[MUD-Dev] Re: Databases: was Re: skill system

[Jon A. Lambert]

On 16 Jun 98, s001gmu at nova.wright.edu wrote:
> On Thu, 11 Jun 1998, T. Alexander Popiel wrote:
> 
> > In message:  <9193945826E7D0118BB4080009DBF8F611737D at TTECH>
> >              jacob langthorn <jlangthorn at towertechinc.com> writes:
> > >
> > >	Has any one tried using Orical or SQL to manage the data base
> > >for the mud? If so what sorta luck did you have?
> > 
> > Yes.  David Passmore and Lydia Leong did an experiment with MUSH,
> > trying to run it off of one of the SQL engines.  They found that
> > it dramatically increased the speed of global searches, but increased
> > the time to get stuff like the list of local objects by an order of
> > magnitude.
> 
> We're working on using either CQL++ (if they will ever get back to me!
> grumble) or mSQL for our DB back end.  I was unaware of specific
> examples of previous attempts, but knew that SQL seemed a bit kludgy for a
> lot of the smaller scale data access that goes on in a mud.  As such, the
> DB is probably going to be used mainly for cold storage, world
> persistance, etc.  Most of the data that is used often will be cached into
> memory and manipulated there.  The downside to that approach is that we
> have to deal with data consistancy issues, etc.
> 

Part of the problem is in mapping a mud's objects to storage.

Mush, MOO and LP objects' attributes are runtime dynamic. 

RDBs are ideal for mapping objects with static runtime attributes.
In order to succesfully map an object with dynamic runtime attributes 
to an RDB, the object must be reflective.  That is it must be at
all times self-aware of it's attributes.  In addition the RDB ideally
is designed in such a way as to implement object reflectivity instead
of the object directly.  This requires an interface or translator 
module.  One can certainly map an object directly to an RDB 
using what static properties are known to all objects and putting the
dynamic properties into a binary blob.  This is quite similar to
the conventional use of dbm and related implementations.  If this
was the implementation of the above mush experiment, then I do
not see very much beneficial in this approach, except to exceed 
any hardcoded limitations of dbm vs mysql. (If there are any?).

The simplest and most easily understandable form of reflectivity in 
storage that I know about would be the DIF format (VisiCalc anyone).
Not that I'm recommending it for use, just for getting aquainted with 
the concept.  It's quite limited.  

Diku, Mud++ objects' attributes are runtime static.     

I believe these server implementations would greatly benefit
from RDBs.  That is if persistence is desired.  
 
> JC uses an OO DB, but not a pre-packaged one, if I recall.  There has been
> a lot of discussion about OO DBs in the past, and some minor discussion
> about RDBs.
 
An OO DB might be more attractive than an RDB.  Since a whole host 
of OO comes for free.  Yet your mud programming language's particular
implementation of OO might have to match or be translated to a form
recognizable by the OO DB.

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--