[MUD-Dev] (fwd) SERVER: Re: New Code Base in VB Started

[J C Lawrence]

Lo Jon!

From: jlsysinc at spammenot.ix.netcom.com (Jon A. Lambert)
Newsgroups: rec.games.mud.admin
Subject: SERVER: Re: New Code Base in VB Started
Date: 22 Apr 1998 05:52:43 GMT

On Tue, 21 Apr 1998 19:38:17 -0700, Chris Dern spaketh...
>
>> Someone (not me) is going to craft a mud with a SQL server
>
>I was wondering about this my self. I'd love to hear from some
>KNOWLEDGEABLE sql professionals out there who perhaps play MUD's, if
>they think that SQL would be a way to go. Basically I have pondered this
>for a while, it would allow a totally persistent world. (Or at least in
>theory.) Just a little thought on my part of the world.
>Chris

I have used three different relational DBs as backends to my server.  
However, using relational technology poses some problems peculiar to 
certain mud designs.  Applications with static object heirarchies map
easily enough to RDBs, but dynamic objects found in muds that implement a
object programmable layer like LP or Cold will require a significant 
effort in the object-relational translation layer to retain inheritence 
(parentage), handle creation/destruction of attributes, provide class 
versioning, etc. while retaining any of the advantages of dynamic 
SQL.  I do not consider SQL in itself to be a major advantage in muds,
however I believe databases, in particular relational, do have some
great advantages.  First is recovery and restart.  Relational databases
are expecially well-equipped to handled point-in-time recovery via
logging and transactional integrity via rollback and commit.  Event
driven systems which require persistent are especially sensitive to
transactional integrity.  Second is concurrency.  Most relational 
databases are especially mature in the ability to handling multi-threaded
or multi-process applications.  Third is security.  Many if not all
rdbs have the ability to automatically encrypt data and provide table 
level security mechanisms which can be integrated into the server design.
Fourth is distribution.  Many relational database servers are mature in 
brokering remote application requests and several can support partitioning
of databases across multiple servers.  

A more ideal solution to the problem would be an OODBM solution.  While
they have been around for many years, small platform performance has been
weak and query languages have been somewhat non-standard and ugly, although
many recent ones support SQL.  :)

My solution in Tycho was to write a generic object-to-relational translation
layer.  That is the underlying db tables do not represent the application
(mud) itself but represent a reflective view of an OODBM.  Interfaces to
the databases are ODBC compliant so I can plug-in anything from Oracle, 
SyBase, Watcom, Paradox, Access, etc. with no code changes.  SQL usage
is relatively minimal and definately ANSI.  I have found no reason or use
for SQL as a query language within the context of the mud programming 
language (mudlib) as it already supports queries since persistence is
language implicit (see MOO, COOL, COLD).  However I do use it in external 
utilities and editors while the server is running (that second advantage 
above).  Because I implement cacheing and locking within the mud server the 
services of the rdb in this area are redundant and unnecessary.  And I have 
recently began an effort to move transaction integrity and recovery server-
side also.  Another feature I have is that all mud code (source, byte-code, 
and native) is stored within the db as well as all versions of source.  A
pleasant side effect is security of source through encryption and a lockable
checkin/checkout procedure similar to the Powerbuilder environment.

And finally the performance argument is a red herring.  I maintain strongly
that most RDMSs will outperform textual/filesystem databases any day in the
land of full persistence.  Even if I was rewriting Diku, I'd still use an 
rdb over a flatfile approach.

--
--/*\ Jon A. Lambert - TychoMUD Email:jlsysinc at nospam.ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--


--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.