[MUD-Dev] Unique items vs. item references

[Smith]

On Mon, 5 Aug 2002, Brian Hook wrote:

> Part of me knows that having a database system that is indexed and
> allows for fast queries is important, but another part of me knows
> that it's a royal pain in the ass to have a machine with mysqld
> running, not to mention database table construction and editing.
> Free text doesn't scale, but damn, it's handy.

This may be a tangential question, but I'm interested to hear
thoughts on it. I'm (fortunately) still designing my approach to the
database, but I see two approaches that have merits, and I wonder if
anyone's found out more about the real-life pros and cons.

Approach 1)

  The dbms is god.

  All data, what would once have been area-files, and the "live"
  data (player records, etc) is stored in the database with little
  or no caching in the application code. All things that would
  normally modify data turn into transactions against the
  database. Only bytes immediately destined for, or immediately read
  from an i/o channel are not stored in the database.

    pros:

      1. Transactional approach implies very good data safety in the
      event of crashes/disconnects/edge cases 2. Representing all
      the data in the database implies very easy access to the data
      through other means than the player interface (reporting
      tools, web-based olc tools, etc)

    cons:

      1. Potentially ugly database layout, great attention needed to
      data normalization issues.

      2. Likely HUGE database even with good normalization

      3. It would likely become a hard problem to roll back to a
      "clean" world (i.e. how do you reset the world, do you
      duplicate "live" and "static" data, spawning the live from the
      static within the database?)


Approach 2)

  Scene-graph approach.

  The database(s) store only data that _must_ be persisted.  Much
  like many graphics programs, the data is read once at load/reload
  into memory and manipulated from there.

    pros:

      1. Fast, even with large data sets

      2. Eliminates the ever-present calls to the dbms (sql tastes
      bad)
  
      3. Database design and data normalization issues are not _as_
      important, even a very large world would probably not have an
      outrageously sized database.

    cons:

      1. Access to the "live" world's data would require use of the
      in-memory data copy, either through an external interface, or
      from within the player interface, this leads to a harder time
      writing olc and reporting tools.

      2. Less data-protection in case of catestrophic failure,
      likely behaves much more like a normal diku derivative, less
      like an n-tier application.

I'm sure that the pro/con lists are incomplete, but I wanted to
sketch out the major differences in the approach. Overall, I'm
struck by the amazing simplicity of the first approach, the ease of
integrating scripting languages (scripts get written in some
language that allows 1, interpretation; and 2, sql; the choices are
nearly limitless), the ease of allowing real-time olc against the
database, the ease of enabling real-time reporting to external
consumers (web-pages, etc). It's a very attractive solution.

But it's 1. Hard (lots, lots, and more lots of sql), and 2. Slow
(dear god that's a lot of database hits to do, well... anything)

Any experienced answers, or wild guesses are most welcome

-dave


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