[MUD-Dev] MUD Design Fundamentals (Was: Looking for

[Jon A. Lambert]

On 29 Aug 97 at 14:25, Brian Price wrote:
> Hello all,
> I'm new to this list so I'll include a short intro in this followup.  
> I'm a 35 yr old computer technician/circuit designer turned programmer 
> who's had an interest in wargames and rpgs since the age of 16 or so.  As 
> I have had a non-formal education, I may at times present concepts  in
> unfamiliar ways.  (the following will no doubt be an example of this)

Hi Brian.  I have similar interests in wargames and RPGs.

> A persistance system is used to take a 'snapshot' of a system or 
> sub-system state at a particular point in time.  The persistance 
> mechanism can then restore the system or sub-system to that earlier 
> state.  

Yep.  The granularity and nature of the persistence can vary widely.  

> It consists of basically three layers; the system or 
> sub-system to be 'persisted', a system to encode/decode the run-time 
> state of the persistant system to a storage mechanism, and a storage 
> mechanism to store that state info.  
>

The model I'm attempting is not dissimilar, perhaps only in 
terminology.  

1) Object manager subsystem - consists of several subsystems
   a) transaction manager
   b) cache manager
   c) database manager

The database manager acts as a translator of a generic OO model into 
a relational model.  It translates inheritance, associations, user 
data types into their relational counterparts.  Late bound DML and 
DDL are used frequently.  

A few general guidelines I've used in my approach:

1) Each class maps to one or more tables. An object instance maps
to a row.  
2) Aggregate classes map to one or more tables. 
3) Many to many associations map to a distinct table.
4) One to many and one to one relationships are implemented using 
foreign keys. 
5) A Superclass and each subclass map to a table.  

Note: I am using single inheritance OO model much like Java's.
 
> A relational db can well be used as the store layer for a 
> persistance model but you lose the structure and type ignorance.  
>

Yes for external programs, unless they access your store through an
object broker, see above. 

> Thus if you change the type of a class data member you must make a 
> corresponding change in the relational db structure.  Although this 
> violates some OO design goals (ability to isolate/encapsulate 
> changes), it has the advantage that the store layer can be 
> manipulated outside of the program that implements persistance.
> Another advantage is that the store layer incorporates functionality 
> that you will not need to implement in the app.
>

True but these changes can be encapsulated as well, if you attempt
a generic object to relational translation rather than a literal
one. 
 
Jon A. Lambert