The total DBMS approach (was: [MUD-Dev] Unique items vs. item references)

[Derek Licciardi]

From: Smith, David (Lynchburg)
> On Mon, 5 Aug 2002, Brian Hook wrote:

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

This is all mere speculation though it comes from my 10+ years in
teh Database arena as an Oracle DBMS consultant and a Microsoft SQL
Server DBA.

I believe you could build a database based architecture like you
describe in scenario one.  I also think that it would be cost
prohibitive to do so for anything larger than a normal sized MUD.
If you're talking about MMOG size, then you're looking at severe
costs.(relative to a typical MMOG or game project) In effect you
would be building something the size of SAP, PeopleSoft, or Oracle
Applications for your transaction system.  Like SAP, given enough
hardware, it runs amazingly fast.  Oracle is capable of handling the
NASDAQ stock market.  It is certainly capable of handling the
processing requirements of a MUD or even an MMOG.  The question
quickly becomes a money one.  SAP, installations run into the 20 -
50 million dollar range and higher to achieve MMOG style subsecond
performance for thousands of users.  The benefit of having a
standardized interface to the game data through SQL simply does not
outweigh the significant increase in cost.

The idea is noteworthy for all of the things you could do better
with the data in the database all the time.  Things like: Real time
reporting using an Off-the-Shelf report writer, automated
datawarehousing for balancing purposes, intricate logging systems,
tied to the DBMS event manager consoles, and the list goes on.  An
additional side benefit is that IT talent is pretty readily
available to write this stuff and doesn't require a hugely expensive
C++ "game" programmer to create the functionality.  Hell, you could
do most of it with Crystal reports and give Off-the-Shelf AdHoc
tools to your CS group.

For a MUD, this might be totally different.  If anyone gives the
approach a try, I'd love to hear how it came out and would be very
willing to offer database design advice if needed.  Even with a MUD,
you're probably not going to be able to do it without a nearly
midrange server.  We're talking about SCSI RAID arrays, Multiple
processors, Gobs of memory, and a qualified DBA that can tune like a
madman.  No matter how you position the database, you're going to
want to write an interface in front of the database that allows
communication with the game client.  The game client should never
have the ability to fire SQL straight to the database.

The prohibitive cost is probably why an all DBMS approach has not
been tried by any of the MMOGs today.  These games do not use a
database as its main live datastore and instead opt for something
proprietary.  I believe DAOCs post mortem stated they were going to
use Oracle until the 900K price tag was dropped on someone's desk.
With other systems such as MySQL and Postgres, I do not believe you
can achieve what you would be striving for in your total DB
approach.  To achieve the total DB approach, you will need MS SQL
Server, DB2, or Oracle along with all of the costs associated with
those databases.

Derek

ps If you disagree with my assessment of MySQL and other such
database holy wars, I'll gladly support myself in Email though a
flame war over what DBMS is better is probably not for the list.


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