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

[J C Lawrence]

On Tue, 16 Jun 1998 13:58:35 -0400 (EDT) 
s001gmu <s001gmu at nova.wright.edu> wrote:

> On Tue, 16 Jun 1998, J C Lawrence wrote:

>> On Tue, 16 Jun 1998 10:46:20 -0400 (EDT) s001gmu
>> <s001gmu at nova.wright.edu> wrote:
>> 
>> > We're working on using either CQL++ (if they will ever get back
>> to > me!  grumble) or mSQL for our DB back end.
>> 
>> I haven't confirmed this, but I've read several reports that both
>> MySQL and mSQL both have performance/scalability problems with
>> large databases.  You may want to investigate this area.

> Can you point me at any particular sites/sources?  

The only one that comes to mind is a recent comment to that effect on
the ICGnu list I host at Kanga.Nu.  I'm about to regen the archive
there for the new WebGlimpse support (should take less than an hour
including code changes).  Suggest you do a search there and chase up
with the poster.

NB If you get in before I get the regen done -- my apologies for the
endless JavaScript errors.  Count it up to MHonArc learning curve.

>> > Did they write anything about the MUSH DB expiriement, btw?  I'd
>> > love to get my hands on any documents they produced.
>> 
>> I've only read references to it.  I suspect that all the real
>> discussion occurred on Marcus Ranum's Wizard list, which was in
>> many ways the equivalent of MUD-Dev 10 years ago (and sadly seems
>> to be last as far as archives are concerned).
>   ^^^^ - lost?  fooey

Yep, lost.  Agreed.  <sob>  

Anyone got a current email address for Ranum?  I'd like to chase up
this area with him.
 
>>> JC uses an OO DB, but not a pre-packaged one, if I recall.  There
>>> has been a lot of discussion about OO DBs in the past, and some 
>>> minor discussion about RDBs.
>> 
>> My current implementation uses a linear TDBM descendant.  In moving
>> towards more of a persistent store model I've gone towards
>> Persist++ and Texas munged into my prior TDBM-like model (and have
>> ended up with a right load of bollocks, if a set of interesting
>> proof cases).

> *blink blink* auf english, bitte?  my DB terminology stops right
> about where I stopped writing in my post... ;)

Okay, in words of few syallables (well, less than
superantidisestablishmentarianialistic):

  I currently use a home-grown hack on TDBM.  TDMB is a pretty
standard (well, clean and logical) extension to the old Berkely DBM.
The DBM library which uses simple hash keys to a variable length
record DB.  Whazzat all mean?  Think "associative arrays" and then put
them on disk.  You can look up a DB record using an index like "Fred",
and store another record with an index entry like #98234.  DB files
tend to grow large quickly, but performance tends to be reasonable as
long as they don't get too large.

  X uses DBM for its colour table lookups BTW.

  TDBM is sweet, fast, and rather sexy.  They have some very good
discoursory material in the tar ball (or was that the FTP site?)
giving performance metrics, design considerations etc.  Very optimised
in some ways.

  However, for minor unkinked reasons I wanted to move towards a
persistent store type model.  Whazza "Persistent Store"?  At the
simplest level, consider the case of being able to add a tag to your
C++ (or other OO language) class declarations to have those instances
automagically stored on disk such that when your program runs again
later, those class instances are automagically re-initialised back to
the old state without your having to touch a single bit of code.
Rmember: This works for any class, encluding pointers to other class
instances, nested classes, etc.  Everything is virtualised on disk
such that it can be later restored to memory.  Note: The Texas
Persistent Store has a number of postscript documents which discuss
this area fairly well.

  I wanted that sort of transparent support for backing data
structures onto disk without having to write data-structure-specific
code.

  Persist++ is a C++ library that does some of this.

  The Texas Persistent Store is another library that offers a
persistent store.

Soo, I took my TDBM-like implemenation and hacked some persistent
store type semantics into it.  I ended up with something that worked
well enough for me to be comfortable that I both understood the area
and had a sense of the metrics involved.  I also ended up with a rats
nets of spaghetti entrails for the code.  It compiles and runs, but
little else good can be said for it.

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