[MUD-Dev] Re: Databases: was Re: skill system

[Jon A. Lambert]

On 24 Jun 98, s001gmu at nova.wright.edu wrote:
> On Sat, 20 Jun 1998, Jon A. Lambert wrote:
> > 
> > Part of the problem is in mapping a mud's objects to storage.
> > 
> > Mush, MOO and LP objects' attributes are runtime dynamic. 
> 
> The first statement is true if you are porting the code bases list in the
> second statement.  We, however, are working on something less ambitious.
> Building a compiler into my code is a bit beyond my capabilities and
> desires ATM.

Yes it poses more problems for these servers.  My other post in 
response to Adam is likely more relevant to your implementation.
  
> > RDBs are ideal for mapping objects with static runtime attributes.
> 
> Bingo.  Not all of us are on the 'fully programable' band wagon.  In fact,
> I think we are not even on the 'completely levelless' band wagon either.

Nod.  You would find me riding on that first bandwagon, but not on 
the second one.  :)

> > In order to succesfully map an object with dynamic runtime attributes 
> > to an RDB, the object must be reflective.  That is it must be at
> > all times self-aware of it's attributes.  In addition the RDB ideally
> > is designed in such a way as to implement object reflectivity instead
> > of the object directly.  This requires an interface or translator 
> > module.  One can certainly map an object directly to an RDB 
> > using what static properties are known to all objects and putting the
> > dynamic properties into a binary blob.  
> 
> Let me attempt to restate the above, to test my understanding.  Please
> correct if I mess anything up.  :)
> 
> There are 2 kinds of objects (to generalize).
> 1) Objects whose properties are compiled in. (A rock is a rock is a rock)
> 2) Objects who can change their properties at run time. (a rock can become
> an intelligent rock on the fly)
> 
> 1 maps nicely to a RDB because each of the objects compiled in simply gets
> its own table, with one column for each property.  

Yes, mostly.

>2 does not map well
> because the setup listed for 1 (one table per object, one column per
> property) will just not work as the properties themselves change and
> changing a table's layout in SQL is ... expensive ... to say the least.

Exactly.  But even that's a relatively minor annoyance compared with
dynamic inheritence.  Changing an objects parentage.

> One suggested solution to mapping 2 into a RDB is to map out the basic
> objects/properties as in 1, and then cram all the changeable ones into a
> Blob field.  The problem is that the blob field then needs to be
> interpreted at run time, essentially recreating a large portion of the DB
> layer in code (storing not only data, but how the data is used).  This, in
> essence, defeats the purpose of using a RDB to begin with.

Right on.  In fact, I think it's a poor solution and wouldn't 
recommend it.   I can't even state with certainty that objects have 
any useful properties in common.  Unless it is assumed they trace 
their parentage to a single root. 
 
> > The simplest and most easily understandable form of reflectivity in 
> > storage that I know about would be the DIF format (VisiCalc anyone).
> > Not that I'm recommending it for use, just for getting aquainted with 
> > the concept.  It's quite limited.  
> 
> Unless I misunderstand, a RDB uses reflectivity, just not as easily
> mutable reflectivity.  You can't just add a new variable on the fly... you
> would have to create a new table, identical to the last + one new column,
> and then transfer all the old data over, adding in the new variable
> somehow.

Yes, but it is reflective of the RDB model; not the OO model.  
That is you see databases containing tables containing rows 
containing columns and tables that have foreign keys to other tables. 
What's not clear is whether these table associations are inheritence, 
aggregation or simple associations.  

If your SQL-RDBMS is ANSI compliant, adding or deleting a column is 
quite easily accomplished with ALTER.  How it is implemented may 
vary.  Usually such a command will escalate locking to the 
table-level, although I've seen RDBMSs which escalate the lock to the
database level. :(
 
> > Diku, Mud++ objects' attributes are runtime static.     
> 
> Yup.
>  
> > I believe these server implementations would greatly benefit
> > from RDBs.  That is if persistence is desired.  
> 
> Yup.  Diku at least has a bit of a DB built in... or at least a chunk of
> code they call a DB, but it hardly resembles any DB I've ever seen.  :)
> 

There is a further distinction here.  Diku contains no notion of 
inheritence, while MUD++ does.    So it is even easier to map.
Perhaps I'll post a DB design for your stock Diku area, mob or
something, just for illustration.  

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