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

Valerio Santinelli tanis at mediacom.it
Mon Aug 12 11:33:35 CEST 2002


----- Original Message -----
From: "Derek Licciardi" <kressilac at insightBB.com>
> 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.

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

I agree with your statement. Having a total DBMS approach is going
to be heavy on the costs side. There's no way to cut the costs using
an Open Source RDBMS since no one can compete with the one you
talked about in your previous statement.

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

I am not going to try it with a MUD, but I was thinking about giving
it a try with UOX3 and MySQL. UOX3 is an Ultima Online server
emulator and is well suited to this kind of conversion. And MySQL is
the choice because it's free and it's available both for Windows and
Linux which are the main platforms used by the emulator. Maybe we
could start working on the project together just for the fun and to
see if that approach could be comparable to the actual all-in-memory
model.

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

I once heard that Ultima Online was actually using Oracle for all
data storage. I still don't know how it interfaced with the DBMS,
though. Maybe Ralph could enlighten us?

--
Valerio Santinelli
One Man Crew Gaming Community (http://www.onemancrew.org)
My Lab (http://tanis.hateseed.com)
HateSeed.com Founder (http://www.hateseed.com)
In Flames Italia Webmaster (http://www.inflames.it)




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



More information about the mud-dev-archive mailing list