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

[Derek Licciardi]

> -----Original Message-----
> From: mud-dev-admin at kanga.nu [mailto:mud-dev-admin at kanga.nu]On Behalf Of
> Daniel.Harman at barclayscapital.com
> Sent: Friday, May 11, 2001 8:35 AM
> To: mud-dev at kanga.nu
> Subject: RE: [MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

[snip]

> -----Original Message-----
> From: brian price [mailto:brianleeprice at hotmail.com]
> Sent: 11 May 2001 00:27
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

>> An OTS or OS RDBMS is not overkill given these requirements, in
>> fact, the entire class of available RDBMS solutions are
>> underpowered, inefficient, slow, and expensive.  An oft touted
>> feature of most RDBMS - SQL - is, in this case, completely
>> unnecessary *and* imposes a significant performance hit for zero
>> gain.  Worse, the use of efficient objects and resultant class
>> bloat is practically impossible to represent in RDB terms without
>> investing an insane amount of development time.

> You previously said that infrequent reads were required. Thus I
> don't see how the performance of an RDBMS is going to impact your
> proposed solution.  Writes are generally fairly fast, its the
> queries that are slow. By not going for an RDBMS you have made any
> type of reporting functionality many times more difficult to
> implement. If you have a large game, then I would imagine
> functionality to measure how many warriors have weapons of greater
> than 'x' affectiveness is something you might want to find out
> infrequently enough to make writing a bespoke tool a pain, but
> frequently enough that having sql is a feature. The same for economy
> reports and such like. With a bespoke object store, any type of
> data-mining is just hideous. Anyway, a well tuned and designed
> database can be remarkably fast.

I agree with Daniel here and would like to add an additional point.
Using modeling tools you will be suprised at the efficiency of
modelling a RDBMS.  If you have the talent in your company, an
experienced data modeller can reduce this investment you speak of into
a respectable development time.  The problems that I see with junior
help is that they all to often make rookie mistakes about how to
design an RDBMS and do not fully understand the ramifications of their
decisions.(ie type table vs check constraint, application ref
integrity vs db ref integrity) Once you fully understand how to design
the model, coding for it becomes simple cut and paste code.  This is
what makes SQL nice is that it standardizes the interface to your
datastore and makes it possible to write libraries like ADO.(which by
the way is amazingly fast) I fail to see how standardized industry
practices can cause a major investment in development time, given
experienced designers and developers.  Given junior developers, even
'Hello World' applications take longer so the argument doesn't stand.

[snip]

>> I've heard all the arguments against OODBMS over the years and all
>> the arguments for RDBMS, and in this case at least, *none* of them
>> hold any water.

> I disagree. I think an RDBMS with a bespoke in-memory cache would be
> the optimal solution.  [ snip lots of good points on failover,
> stability and scalability]

> Now whilst you could write your system to avoid some (but I doubt
> all) of this, I would need a lot of convincing that it would be
> wise.

> Dan


My only other point that I would like to add to Daniel's is that given
a well known RDBMS and not a home grown datastore API, you will be
much more apt to find qualified talent to help you manage the game.
With your own API, you can only hope to find someone who is
knowledgable in RDBMS and gets all the foundational stuff behind them.
Sadly your average MCSD or Oracle Admin knows plenty about the
database but usually has no clue about the inner workings of BTree
indexes, Bitmapped indexes, caching algorithms, and such.  As a result
of this, they lack the framework with which to relate your API to some
common ground that they understand.  In other words, 95% of the DBAs
out there today will struggle with your home grown system, whereas
with a widely used database it is possible to eliminate the learning
curve and find the proper talent.  This will allow them to focus on
learning your model design versus the underlyings of your database
management system.  Sometimes performance isn't the only measuring
stick we should use.

Derek

ps IMHO, I think it is time that MUD servers began to become
Enterprise level in quality and design.  I think one could design a
large stable, scalable solution using some of todays business
technology.  RDBMSs and TP Moniotrs come to mind real fast.
Clustering technology, and server farming also come to mind.  All of
this requires much better design than what is currently out there
today, with possibly the exceptions being the large commercial
graphical MORPGs.(I assume they already have some of this)

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