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

[s001gmu at nova.wright.edu]

On Sat, 20 Jun 1998, Jon A. Lambert wrote:

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

The first statement is true if you are porting the code bases list in the
second statement.  We, however, are working on something less ambitious.
Building a compiler into my code is a bit beyond my capabilities and
desires ATM.
 
> RDBs are ideal for mapping objects with static runtime attributes.

Bingo.  Not all of us are on the 'fully programable' band wagon.  In fact,
I think we are not even on the 'completely levelless' band wagon either.

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

Let me attempt to restate the above, to test my understanding.  Please
correct if I mess anything up.  :)

There are 2 kinds of objects (to generalize).
1) Objects whose properties are compiled in. (A rock is a rock is a rock)
2) Objects who can change their properties at run time. (a rock can become
an intelligent rock on the fly)

1 maps nicely to a RDB because each of the objects compiled in simply gets
its own table, with one column for each property.  2 does not map well
because the setup listed for 1 (one table per object, one column per
property) will just not work as the properties themselves change and
changing a table's layout in SQL is ... expensive ... to say the least.

One suggested solution to mapping 2 into a RDB is to map out the basic
objects/properties as in 1, and then cram all the changeable ones into a
Blob field.  The problem is that the blob field then needs to be
interpreted at run time, essentially recreating a large portion of the DB
layer in code (storing not only data, but how the data is used).  This, in
essence, defeats the purpose of using a RDB to begin with.

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

Unless I misunderstand, a RDB uses reflectivity, just not as easily
mutable reflectivity.  You can't just add a new variable on the fly... you
would have to create a new table, identical to the last + one new column,
and then transfer all the old data over, adding in the new variable
somehow.
 
> Diku, Mud++ objects' attributes are runtime static.     

Yup.
 
> I believe these server implementations would greatly benefit
> from RDBs.  That is if persistence is desired.  

Yup.  Diku at least has a bit of a DB built in... or at least a chunk of
code they call a DB, but it hardly resembles any DB I've ever seen.  :)

-Greg