[MUD-Dev] Database vs. Disk

[J C Lawrence]

On Sat, 17 May 2003 11:03:25 -0400 
tom  <tom at interspaces.com> wrote:

> Greets, I'm sure this has been addressed before, although I haven't
> found anything really direct so far. Aside from conjecture, does
> anyone have some practical experience using a database as opposed to
> disk for storing MUD objects, or projects and experience similar
> enough.

First you need to clarify what you mean by a database.  RDBMS?  Object?
Hierarchal?  Tuplespace?  What?

Assuming RDBMS (as that's the most common form of the question), yes,
there are several here that have been down that path with various levels
of pain and success.  In my case I accorded it a dismal and utter
failure due to the fact that my object space and the manipulations I
wanted to perform just didn't map worth a damn to a table-based
metaphor.

  Briefly: I had a runtime morphic soft-code system with dynamic
  inheritance and actively mutating and redefining objects.  Trying to
  wrap that decently in an RDMBS was not something I found acceptably
  possible.  How can I represent the methods and attributes of an
  object, if the basic structure and schema of an object is decided and
  edited dynamically at runtime?  If I'd been willing to not be runtime
  morphic, to not use dynamic inheritance, and to not have a rather
  curious inheritance model in the first place (based off my soft code
  system) then it would have been much easier.  In the end I found a
  simple dbm derivative based off tdbm with external index structures
  (see the list archives for details) and heavily cached abstracted
  lookup tables to be the most effective for my needs.
 
> We're considering moving to database because it'd provide us alot of
> extra versatility, but I'd like some informed opinions. Not so much
> whether a SQL database would be more efficient, but would it be
> drastically inefficient on a MUD with a large number of objects
> (500,000 to 2,000,000)?
 
What sorts of objects?  Behaviours?  Lookups?  Operations?  Is this
something relatively static ala Aber or Diku?  Something runtime dynamic
ala LP?  Something runtime morphic ala the Tiny* clan or MOO?

> I know it depends on many factors, let's assume a mySQL database
> without alot of bells and whistles on the DB end (stored procedures,
> etc.).

Choice of exact database implementation is the last and least
interesting point.  You need to start out with what you want to do, what
you want to gain, what you can't afford to lose, and then a pretty
accurate concept of both your object definition space and its
behaviours.  "Database" is not a magic wand.

Remember: The filesystem is fundamentally a database, as are flat text
files.  The differences are in structuring and supported operations.
 
> I'm not trying to start a holy war, I just wanted some practical
> advice on whether this is even worth considering, and maybe some
> blantant issues we should be aware of by attempting it.
 
Databases are a tool.  

To a man with a hammer, everything looks like a nail.

That's not a smart way to work (or cook dinner).  Instead, start with
the problem, make sure you understand it fully, carefully phrase it in
terms of, "I need/want to have ..." and THEN pick the exact tools best
suited to that problem and your intended method of assault on it.  Don't
skip the bit about phrasing the problem, its quite critical to get it
expressed in terms of a concrete measurable, preferably tangible
products.

  I want to have reports showing the distribution of economic activity
  over the game world and player base, viewed by correlations like...

  I want to have changed fundamental inheritance structures at
  runtime without creating logical inconsistencies in the running
  game, or a perceived lag in play longer than N milliseconds.

  I want to have lookups to objects by unique ID in less than 5ms, with
  lookups of object sets by inheritance from a unique ID in less than
  50ms.

  I want to...

Start with the GOAL, then figure out what you have to DO to get
there, then WHO and what you have to BE to do that 'how' to get that
goal.

  That mountain, that path, this human.

Changing the order is a recipe for something you don't want.

  ObNote: Bruce Mitchener pointed me a while back at some excellent
  discussions on another list about various schemas and models for
  object definitions for games (gdalgorithms?).  There was good stuff in
  there that you might like to look at to help understand how game
  objects can be constructed, manipulated, etc in useful and sometimes
  surprising fashions.

--
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev