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

[J C Lawrence]

On Thu, 25 Jun 1998 01:51:25 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

> It is particularly important to develop unique OIDs (object IDs) to
> use as keys in the design of tables.  If you are implementing
> concurrency or a distributed environment, the mechanism for
> assigning OIDs needs to be even more robust.  Using anything from
> the problem domain (i.e. user name, etc.) as table keys creates a
> mess of maintainence and access problems.

> Object attributes can be mapped to SQL-RDBMS columns.  But since
> RBMS usually only allow data primitives, sometimes it makes better
> sense to map nested structures/ADTs to one-to-one table associations
> and sometimes fold them into the class table.  It depends.

Systemically the question of dynamically added and removed columns
would seem a problem.  

> One can map objects directly to classes and instances to rows, or
> joined rows as with ADTs, there are some other ways to implement
> inheritence.  For instance you can map entire class heirarchies to a
> single table.  

This becomes difficult with multiple inheritance.  Heck, most things
become difficult with MI, and this is merely one example.

> The method I like best is the direct class to table approach since
> it preserves the spirit of OO.  However, the ease and speed of
> access is directly related to the depth of your inheritence tree. :(

Not knowing how the performance metrics of databases are related to
table count (what happens when you start having thousands or tens of
thousands of tables?), as well as table size (what impact does the row
count have on performance, especially when compared to the percentage
of "interesting" rows?  (eg which is better: a single 10,000 row table
with 20 interesting rows, or a hundred 100 row tables each of which
has small chance of having anything interesting?)), I've been playing
with abstracting the internal logical relationships from the DB
entirely, and almost using the DB only for access and storage, and
leaving the logical interpretion of that storage to the internal
language.

Don't know if its a useful approach (remember, I've been out of the DB
world for nigh on 10 years now). but the basic idea would be to have
one table which held only ObjectID's (a system-wide primary key) and a
deleted/live status for that object).  Another table would hold tuples
of ObjectID's and method definitions (soft code and byte code).
Potentially each method definition would be its own table with one row
per referencing object, and one collumn per internal state variable
(and two for the code representations).  Another table would hold
tuples of parent and child inheritance ObjectID's.  Etc etc etc.  All
very very simplistic.  An entire object definition (which would
enclude its state) would be the product of the orws from a very large
number of tables.  The actual intelligence of the DB in regard to
processing object characteristics doesn't get used at all -- that's
all abstracted into the internal language which maintains the sense of
the structure in its own logical constructions.

I'm not even going to comment on search/access overheads for the above
as I haven't even tried it yet.

This of courses raises a fundamental design point: To what extent
should the DB be a reflection of, or should support and or directly
represent the logical construction of the soft code language?  A
persistent store is the ultimate in tieing the DB side to the logical
structure yada yada of the language.  The standard MUSH/Tiny-*/Cold
dbm approach is far out at the other end of the scale in making the DB
represenation opaque in its relation to the language internal
structure.

I realise that the above is heavily counter to the "heavy DB" model of
the universe.  Still wondering why I should care however.

Note: Metrics on MySQL performance can be found at:

    URL:http://www.mysql.com/benchmark.html

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