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

[Brian Price]

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)

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

A relational db corresponds to the store layer in a persistance model 
with one major difference, the store layer in a typical OO 
persistance model is unaware of the structure and type of stored 
data.  A relational db can well be used as the store layer for a 
persistance model but you lose the structure and type ignorance.  

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.

If your app is implemented in a langauge that supports runtime-binding, 
(Smalltalk, LPC?, etc) the dumb store would be more appropriate since 
you are more apt to need to make changes at only one place.  However 
you may need to implement more sophisticated knowledge extraction 
mechanisms.   If you find yourself in need of the ability to query 
the data, do updates, perform transactions you must provide those 
capabilities in your code.

On the other hand, if you are implementing your app in an 
early-binding language (C,C++, etc) you might well consider using an 
rdbms as your persistance store.  Primarily because you will need to 
write less code to achieve the same ends (data import/export, 
external data manipulation, queries, updates, transactios, etc.).  
The drawback is, of course, that you must keep your object model and 
your db model in sync.  

If your chosen rdbms supports meta-functions, you could perhaps 
design a persistance system that automatically updates 
the underlying db for changes in the object model.  I'm not sure of 
the practical use of this, but it is quite possible to have a new 
class implementation check the db upon first instance creation and 
update its fields/tables as required.  This would restore the 
encapsulation of changes feature of the dumb store at the expense of 
an increase in complexity of implementation.

In closing, the persistance vs. rdbms argument is not necessarily an 
either-or question.  In some situations it may prove profitable to 
combine the two approaches.  I hope this helps to clarify the picture 
a bit.

> At 03:47 AM 8/29/97 PST8PDT, Ola Fosheim Groestad wrote:
> >Jeff Kesselman wrote:
> >> engine ala Cold or Smalltalk.  This is akign to the 'realtional databes"
> >> oidea where everythitgn is stored as tables, ebven the sturucture of the
> >> data itself.
> >
> >I don't think of this as persistence. By persitence I mean something
> >like handing a reference to an object and tell the persistence system to
> >save the object and everything that object refers to unless something
> >else is specified. A database is something else, I may be wrong..
> 
> A relational database really is jsuta way of organizing data on the disk
> drive.  The inetrface coudl be what you describe or a standard table-type
> generic inetrface.  In iether case a dataabse coudl be living under neath
> to ragnize the data.
> 
> An "object orinted database" is a lot mreo like what yo udescribe BUT the
> problem qwith your descriptionj is that it make sa concious act of storing
> and retrieving necessary. Many "inhearently p[ersistant" systems (such as
> cold or Smalltalk) do NOT require such an active effort.  In genral the
> difference is in tehcnase of cold or Smalltalk the persistance is built
> into the system, in the case of a C++ persistance library it is an add on.
> 
> But ANY system that can store the values of obejcts and recreate them from
> a secondary storage device ghas the quality of "persistance". Lieterally
> persistance comes from the english verb "to persist" or to continue to exist.
> 

Brian Price aka Delver <blprice at bedford.net>