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

[J C Lawrence]

On Tue, 30 Jun 1998 02:57:01 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

> On 25 Jun 98, J C Lawrence wrote:
>> On Thu, 25 Jun 1998, Jon A Lambert wrote:

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

> The sheer numbers of tables usually isn't as important as the number
> of table joins one must navigate to retrieve an object instance.  

So I've found in crude testing.  Index searches are fast as long as
you don't have to do many of them.

> In any non-trivial object diagram there will usually be multiple
> paths to access an object instance.  Ideally or unfortunately this
> goes back to your design.  For example, the glowing torch in Bubba's
> hand might be accessed by starting at object Bubba and traversing
> Bubba's inventory list; or perhaps in some contexts, a short circuit
> is faster like starting at object RoomX and accessing LightSource.

So far I've been very effective in convincing myself that an SQL base
is not well suited for a runtime morphic and irregularly patterned (at
least as a class heirarchy) MUD.

Ahh well.  Methinks I'll have to move Kanga.Nu over to an SQL base if
I'm gonna learn SQL.  Much more reasonable.

> Although I cannot fathom a mud having 1000+ tables.  

> As a matter of fact, I haven't worked with a single application,
> IRL, that had more than a couple hundred tables.  Although I've been
> in shops that have 1000's of tables, but this was for their entire
> suite of applications.

Think one table per object class and a fairly well developed object
heirarchy (free user programming).

> You may be talking about what I call adhoc querying or "what if"
> queries.  Like, How many steel broadswords are there in the world?

Yes.

> The differences in time can be dramatic.  OTOH, how frequent is this
> query?  If it's quite frequent in softcode (economic simulation
> perhaps?), then the index makes sense.  In addition, the more
> indexes on a table , the time to insert a row is increased.  The
> solution is measurement and tuning, as new features are added into
> the server.

<nod>

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

> Exactly.  A translation layer.

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

> Hmmm...  First and second thoughts.

I wondered how long that phrasing ("first thoughts") would take to get
repeated.  <kof>

> Construct an abstract object model of the object model that the
> softcode follows.  Even if you not using relational technology, I
> think this is the way to go.  

Already done.  Thus the map for ObjectID to method list, to
containment directives list etc.  The structure is actually very
simple: just four lists (of lists) with an ObhectID tag at the top.

> How many OO-DBMS's or P-Store systems follow your softcode OO model?
> Probably none, right!?

I can't comment on the OODBMS end, but that's *exactly* what
persistent stores do.  At an idealised level a persistant store is
rolled into code as follows:

  class persistent bubba {
    public:
      lotsa methods();
    private:
      lotsa more_methods();
  };
    
After that all instances of the bubba class are automagically
persistent, and by their very nature follow your internal model as
that's what your code-model follows (doesn't it?).  Ideally you never
see or care about the storage format, indexes, record types, tables,
joins, inserts, etc.  You just behave as if you had unlimited
battery-backed RAM.  The peristent store merely adds a new flavour
modifier to the volatile/automatic/static/const set.

> Perhaps we should be discussing softcode OO models rather than DB
> implementations.  Is the softcode-OO-model like Java, C++, ColdC,
> LPC, etc.?  Single or Multi inheritence?  Is there a distintion
> between object and class?  Are inheritence and attributes dynamic?
> Are there built-in or native objects?

The OO model is rather ColdC-like (slightly Python-ish but not quite),
with multiple inheritance, clear seperation between definition and
instance (object and class), with inheritance and attributes being
dynamic.  There are a variety of primitive native objects and
(currently) no ability to create ad-hoc ADT's (alas).

> If one takes a close look at commercial (and freeware) OO-DBMS's,
> you will notice that in many cases the package includes an access
> language that reflects the particular architecture, perceptions and
> interpretations of what the designers' think is OO.

<nod>

> What you (and I) are doing is really designing the architecture of
> an OO-DBMS.

<sigh>

>> Note: Metrics on MySQL performance can be found at:
>> 
>> URL:http://www.mysql.com/benchmark.html

> Neato.  What's this Oraxle 1.0 thing?  Upon first (mis)reading my
> jaw dropped thinking MySql beat the crap out of Oracle!?!

 I believe that Oraxle == Oracle, and yes, (I've been told that) MySQL
does beat the pants off Oracle.  Then again MySQL doesn't do
transactions, rollbacks, support the full SQL command set, has limited
locking features, no security model, etc etc etc etc.  Its operating
in a much smaller and less featured field.

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