[vworld-tech] RE: databse usage

[Patrick Dughi]

> We currently do not have mutiple servers, but I'm glad you brought
> that up because the DB strategy will affect that and vice versa.

	I hope I'm not swinging too far off topic here, but one of the
biggest issues I want to tackle is 'how to run this one more than one
machine'.  I've seen/dealt with many smaller MUDs, each of which tackled
the ideas behind dynamic/static data and usage of a cache, to varying
degrees of success.

	As noted above, multiple servers will not just 'affect' the DB
strategy, it's that the DB strategy is directly controlled by the
multiple server system.

	Well, maybe.  

	At least we can agree that multiple servers introduce what I
would hope is a known field of problems; 

	- if caches, what about stale caches.  If not, database
resources and timely responses?
		If you're caching your data and it's spread on multiple
machines, do you distribute your changes, mark data as stale, and how to
communicate to and from both the client and the database.  If you make
the database god though, you'll eventually overload that one god, so
then what?  How do you deal with polythesism?

	- synchronization vs. distribution
		Do you store the same data in multiple places (see above
for problems with caching and synchronizing caches), or do you
distribute it?  How do you distribute it or manage
close-enough-to-real-time synchronization?

	- (a bit off pure database/cache issues) is transfer of control
allowed (for example, a machine per world/zone/arbitrary decision)?  If
so, how is it managed?

	Of course, there are also wide-overreaching issues too, such as
abstracting each tier, network load balancing, and others.

	What I really want to hear is a whole strategy I can worry and
pick at, and argue about the pros and cons.  I don't want to propose
this strategy because I honestly have never run a system on multiple
machines - where it mattered.  That is, I've never had more than one
machine per 'function' - database, login server, the whole
'client-server' paradigm that everyone's now calling the MVC setup
because suddenly everyone's an OO programmer.  I've used javabeans as
more-or-less transparent middle tiers, but I don't actually want to
write a java-based MUD - and you still have many of the problems above.

	Is someone willing to post a generic top-to-bottom system design
that could be (assuming it's workable) used by both small developers and
the guys batting in the big leagues?  Even if it's just an electronic
equivalent of scratches on a napkin - maybe the list can help flush
these ideas out?  If someone's willing, I could even provide a
hypothetical resource & requirement checklist; _x_ machines of _x_ type,
_x_ players at a time, etc.

	This came up before when I was actually asked about network load
balancing.  I know it's possible, I know what it does, I've even worked
on/with systems using it, but I was never the system architect in those
instances .  How does 'everyone else' do it?  What decisions get made?

PjD

P.S.  Next time, I'll try answering some questions instead of only
asking them.