[MUD-Dev] Unique items vs. item references

[Sean Kelly]

On Thu, 8 Aug 2002, Smith, David (Lynchburg) wrote:

>   The dbms is god.

...
 
>     cons:

unnecessarily slow.

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

cons:

  No real advantage over flat-file storage.

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

While the first approach may be a bit slow, I don't think it's hard.
The greatest problem would be what to do if the db connection went
down.

I think this was discussed in a thread about 6 or 8 months ago, but
there are a number of other approaches you didn't mention.  Rather
than go into all the various permutations, I'll mention the approach
I'd likely take:

Store (at least) everything in the database necessary to restore
persistent game data (houses, contents of player chests, etc, if in
a UO-style world) as well as player-specific data (player
inventories, etc).  Beyond that, it's a matter of how much more
complete you want to get.  ie, whether being able to completely
restore the game state in the event of a crash is a worthwhile
expense of development time.

Load information as needed from the database and keep it in memory
until it's no longer needed.  If this data changes, queue an update
to the database.  If you're storing information that changes
frequently (such as player location), store either at a regular
interval, when a player changes areas, or if a player moves more
than a predefined distance from the previous location.  ie. set
delta thresholds.

With the above method, you get the performance of a memory-based
system with the data integrity of a transactional system.  Worst
case in a server crash is that you have a timewarp equal to the
number of queued DB transactions that didn't make it in before the
crash.

One important consideration, however, is what to do when you perform
a transaction in-memory but the corresponding queued DB transaction
fails (not because the DB crashed but because the transaction was
invalid for some reason).  In a well-designed system I grant this
shouldn't happen, but assume it does.  Do you execute a rollback
procedure in the game, allow the game state and the DB state to get
out of sync, or what?  I'm mostly thinking of things like player
trades, purchases, or pick-ups from kills.  Still, the delay between
the in-memory transaction and the DB transaction would likely never
be more than a second or two.  If this problem turns out to be too
much of a headache, you could always do critical DB ops inline and
queue only the less-critical ones.

A good design with a backend database can be incredibly fast.  And
if load becomes too great three's always clustering.  In a previous
job at a telco, I was doing high-volume realtime telephony
processing that stored everything (menus, prompts, etc) in a SQL
database.  There was never an instant of lag in the system, which
was critical because people don't expect lag during a telephone
call.  And this system did all its DB operations in-line (like your
first example).  So don't discount SQL performance without some
design experimentation and load testing.


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