[MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

[Alex Kay]

----- Original Message ----- 
From: <Daniel.Harman at barclayscapital.com>
To: <mud-dev at kanga.nu>
Sent: Tuesday, May 15, 2001 6:27 PM
Subject: RE: [MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

> In the end, I think the basis of the argument is that both Derek and
> I are talking about large scale systems, and that you probably
> aren't. Having said that even on a smaller system, I think a lot of
> the arguments still hold.

> A lot of people seem to make a lot of assumtions about database
> performance without actually benchmarking, I'm not asserting that
> you have, but I'm just refuting a lot of the arguments these people
> put forward, as most are unfounded.


While I won't pretend to be anymore than a 'hack' in this field, I
have implemented a financial 'thick client', flat file (QBasic4.5,
random I/O) multi-user database system way back in 1992. It's still in
use today much to my annoyance as I still have to support it from time
to time.

Now we made this system quite robust, abstracting the I/O routines
into a library and using some funky tricks to avoid having to write
seperate functions for each file/record type (this was no small chore
in QB4.5).

For fault tolerance we also designed it to similtaneously update a
duplicate dataset on a second server located at a WAN node. This also
serves to improve performace at that node as we can dictate which
server a client reads from, all writes however occur to the 'primary'
server first.

But then we extended the system to a third WAN node which does not
have a server and as both datasets still need to be updated,
performance is much poorer at this site. I also needed to rewrite the
method of adding records due to some strange problems caused by
latency, and also discovered a quaint problem with NT Server's
'opportunistic locking' which I had to disable.

Nevertheless, for it's daily function the system is quite robust and
efficient with performance only really an issue at that third node
which could be alleviated by removing the second dataset (which whilst
nice for redundancy at the time of implementation, is no longer
required due to RAID arrays and other backend systems we have since
implemented).

Having said all that, would I do it again? Not on your life. Querying
this sucker is SLOW and all but impractical as the dataset grows
rapidly in size day by day, month by month, year by year. Also, fixing
errors when they occur can be a nightmare (and they will happen).

I have since written and administered a number of small (Access level)
systems since then and their is really no comparison. Any performance
loss for the simplification of development and support is well worth
it.  And the inherent robustness and scalability of an RDBMS is not to
be underestimated.

Alex

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