[MUD-Dev] Unique items vs. item references
Smith
Smith
Thu Aug 8 10:20:34 CEST 2002
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
More information about the mud-dev-archive
mailing list