[MUD-Dev] Re: Databases

[J C Lawrence]

On Tue, 18 Jan 2000 13:28:02 +1100 
Kevin Littlejohn <darius at connect.com.au> wrote:

> Others: gadfly (python-based, if you know the layout of your
> tables it's probably fastest, but equates out to having all data
> in memory at all times), mSQL (dunno, haven't looked at it for a
> long time), Oracle (overblown, slower than MySQL, but by $DIETY it
> does everything, including 'connected by', which would be a _joy_
> to use - provides for object hierarchies really nicely),
> PostgreSQL (which _does_ look nice, and has some nifty tricks that
> may help on the OO side...  But which I couldn't fathom large
> object/blob support for, so I gave up early).  The list goes on,
> of course... ;)

FYI there are various links in the Library at Kanga.Nu ot DB and
storage mechanisms.  The Free DB list is also referenced (it's been
the food for a variety of threads here for such things as persistent
stores ala Texas, transactional models ala TDBM etc.

> There _are_ OO-specific databases out there - Oracle have recently
> (with 8i, I think) started adding an OO layer to their stuff, so
> you can treat things as 'objects' inside the db, and let oracle
> work out how to map that best.  That's hackish, I suspect, but
> presumably works into their XML support as well.  Would not the
> OODBMS's of this world put you a good way toward this?

Direct representation of objects and object heriarchies in a DB is
only part of the problem, and in my case one of the smaller and
simpler parts of the problem.  The problem for me, and for several
of the other OO oriented servers on the list, is that none of the
OODMBSes support runtime morphism of the object heirarchy.  Its a
large and non-trivial problem.  I'm aware of efforts being made in
academia in the area, but nothing that I consider is actually usable
at this point.

> My attitude is still that databases do some things really well -
> storing data, and for relationals, working out what links to what
> - and while they may not be _ideal_ for muds, the chance of any
> given mud thrashing any given database is still pretty slim at the
> moment.  It seems as though db's are generally a win over flat
> text files, so even if you use them as a strange sort of disk
> space, they're a win - let alone abstracting and playing with some
> of the other tricks they'd allow.

I agree.  While an RDBMS ala SQL is arguably not optimal for the
runtime support of a MUD DB, it offers direct and useful advantages
for world analysis, game balance maintenance, and other back-end
operations.

Consider the advantages from an admin perspective if you could query 
your MUD ala:

  Of those characters that have killed Bubba, what were the most
  frequent spells and weapons as compared to the most effective
  used in total damage to Bubba?

  How many players have attempted quest XYZ, and what was the
  average distribution of times required for them to solve it?

  How many characters encountered object XYZ and then were found in
  location QRS within T time later?

  How does player motion in terms of routes across the game world
  vary by time of day?

Given sufficient logging trails in an RDBMS (and SQL as a well known
framework to access it), you can both answer queries like these, and
attempt to do useful things with the results.

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev