[vworld-tech] RE: databse usage

[Alex Chacha]

>Bridatabase said:
>Right, there was a "database is God" thread on Mud-dev a while ago on this 
>subject, but my gut instinct is that hammering the DB for every object 
>access would be bad with, say, 1000 players connected, but since I don't 
>have the ability to connect 1000 players and measure the results, I'd be 
>curious if others that are doing "database is God" schemes are having okay 
>performance.

There are two types of data you will encounter, static and dynamic (I know 
this
may sound like an overgeneralization, but bear with me).

Static content is a property of the world such as building locations, spawn
cycles, textures, static NPC spawns (quest related, ambiance, et. al.),
itemization tables, traps, NPC properties, spell properties, ability 
metadata,
etc.

Dynamic content is player location, statistics, quest info, inventory, non-
static NPC location and statistics, environmental conditions, spell effects,
etc.

Static content can be cached as you don't expect it to change very often 
(can
use either a lazy cache or preload the data).

Dynamic content needs to have a whole different database strategy.  This 
data
must live on the database as it will be used to keep all your servers in 
synch.
You also need to develop an intelligent strategy for writing dirty bits and 
to
constantly update it with changes (such as NPC movement, combat, spells 
being
cast, etc).  In this case the database is a repository for all common
information that your world servers have to share.

Static issues are easy to solve, you can cache as needed.  The dynamic 
issues
will probably keep you up at nights thinking of ways to optimize 
reads/writes
and which transaction model to keep. I think it is very important to divide 
your
data into these two categories, then get 2 separate machines and make one 
static
and one dynamic.  As you scale the data you can then evolve the two machines
into clusters.  Sure at first the dynamic database may seem like a single 
point
of failure, but that problem needs to be solved on the physical level with
hardware rather than with distribution and software.

As far as how to keep the data in synch, you will need to develop some 
mechanism
for querying the database for changes and updating it with local changes.
Whether you use a polling system or a subscription system is all up to you 
and
how you design your network topology.  Just draw a diagram of how your 
servers
will be configured (even if you are running everything on one machine) and 
see how
growing your system will affect how you keep the data in synch.

I am sure more can be said about this, but this should be enough to get you
started.

_________________________________________________________________
Let the advanced features & services of MSN Internet Software maximize your 
online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/