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

[brian price]

> From: "Derek Licciardi" <kressilac at home.com>

>> -----Original Message-----
>> From:Daniel.Harman at barclayscapital.com

[snip]

>> -----Original Message-----
>> From: brian price [mailto:brianleeprice at hotmail.com]

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

[Note: see my followup to Daniel's reply]

> 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 development time required depends upon the number of classes, the
depth of the inheritance tree, and the degree of interdependence
between classes.  With an OODB type object store this is a non-issue
but with RDB it is a complex issue that is not only difficult to
design correctly initially but is increasingly difficult to maintain
as the object model is extended.  Given a well designed OODB-type
system and tools to auto-generate marshalling/serialization stubs, the
required dev time approaches zero.  RDB dev time increases
exponentially with object model complexity.

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

With an OODB-like persistent store system, the store is largely
transparent to the implementors of classes for the object model.  No
matter what approach, standardized or not, you employ with a RDBMS in
this case you will have two models to contend with - server 'game'
object model and RDB model.

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

With the persistent object store approach no DBA is necessary - there
simply is no complex database to administer - there is only the
runtime object model and its persistent image.  Even junior level C++
programmers have found object persistence to be an easy concept to
grasp and implement.  Extending object persistence to an OODB-like
persistent object store can result in a simple API which is well
within the grasp of such programmers.

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

You could well follow such an approach and get good results.  With a
large dev team and a full scale commercial MMORPG project it is likely
that such an approach as both you and Daniel advocate would be
preferable for business purposes if not technical ones.  However, for
a small scale commercial MUD/MORPG, I am of the firm opinion that
OODB-like persistent object stores are well worth considering.

Brian Price
-=have compiler, will travel=-
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev