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

[J C Lawrence]

On Sat, 20 Jun 1998 04:17:25 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

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

The other part of the problem is mapping the storage to the soft
language.

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

Quite, and is so far the approach I am considering taking.  While I'm
not entirely clear on your use and definition for "reflective" and
"self-aware" above (please expound), your mention of a translator
module would seem to suggest that you are looking at the same type of
model I am: various meta tables (mostly containing the names of other
tables) which are used to define the structural relationships and
their significance between the tables.

Thus for instance as I have multiple forms of containment outside of
the basic "The brick is in the bag" (eg what area is the object in,
what realm is it in, does it belong to any super-class object sets
(cheaper than inheritance), weather patterns (in the storm), etc), I'd 
have a table which merely lists the tables which express the various
forms of containment and their human-readable significance.  A custom
translator would recognise the significance of this meta table, and
thus in browsing the DB display the appropriate relationships
accordingly.

Am I anywhere near the right camp?

Yes, there is very few benefits that I see over th opaque DBM blob.
Performance is not one of them.  The main benefit I see is that the
use of such an external (and to the soft code opaque) DB encourages a
little more structural rigour on the soft code design, which in turn
makes external browsing easier (consider the number of ways of
implementing or re0inventing containment in soft-code, as versus
adding a table entry and having the rest fall componenet-wise in your
lap (cf Usenet thread)).

BTW: an article some of you may be interested in on programming
characteristics:

  URL:http://www.salonmagazine.com/21st/feature/1998/05/cov_12feature.html

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

Quite.  Using an SQL base to implement a DBM analogue seems curious if
that's what they did.

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

URL:http://www.ipahome.com/gff/textonly/summary/lotusdif.htm

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