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

[J C Lawrence]

On Wed, 8 Jul 1998 02:30:28 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

> Merged several messages together here. :) 

Polyamory!

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

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

> Right.  Then again the same problems rear there ugly heads in using
> OODBMSs.  Most of these critters are as static as RDBMSs.  Runtime
> dynamism is rather unique to our problem.  I don't believe many
> persistent storage mechanisms even recognize runtime dynamism.  A
> good place to look for mechanisms may well be in Smalltalk
> literature.

Quite.  I am >this< close to giving up on the RDBMS approach (again)
on account of it just being too resource (especially CPU and IO)
intensive for the benefits gained.  Early simplistic fiddling here has
mostly convinced me that its far too heavy a solution witout obscenely
high percentage DB_size cacheing requirements.

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

> That's where I started.  The only problems come at the point where
> dynamic primitives (attributes) are mapped.  They can be mapped to
> separate tables by type or to a single table with columns for each
> possible primitive and typing information.  Either approach makes
> adhoc native SQL querying more difficult.  Unless you've constructed
> a query interface that filters attribute typing information. :)

Bingo.  Additionally I found that while table lookups on indexed keys
are cheap, they are not free, and that I do one hell of a lot of
cross-attribute mapping resulting in the old equation of

    <very_cheap>*<large_number> ==  <expensive>

<Sigh>

Ranum's comment of tieing the code to the object is coming home to
roost -- it looks like monolithicly stored internally structured
objects damn near required for performance (tho I probably should play
some more with Texas first).

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

> Yes, but they are not runtime dynamic.  Classes/Object attributes
> are fixed at compile time.  :(

<cock eyebrow>

One could, perhaps, put the persistance libraries underneath something
like CINT (HP's C/C++ interpreter) and thus have them be runtime
morphic.

<!smug>

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

> Do you have singleton instances of class objects, like C++?  

Semi.  The base design is there, somewhere, but the implementation
sucks rocks.

> Do attributes and method code reside in the class, object or both?

In design in the class, in practice it varies depending on when I
wrote the heirarchy in question.  ie The language actively encourages
class/instance seperation, but does not outright require it (it
should).

> My model closely reflects C++.  However all inheritence is private
> and thus the softcode model strongly favors composition and
> delegation over inheritance.  Methods and attributes can reside both
> in class instances and in object instances (aka C++ "static").  My
> native objects could best be described as Java interfaces or COM
> objects but they cannot be inherited.

<nod>

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

>> <sigh>

> <insane cackling>

Golly.  You're still tat sane?

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