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

[Jeff Kesselman]

At 02:26 PM 8/29/97 PST8PDT, you 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 

A side note.  The difference between your practical approach based on what
you've seen rdbms' do, and my theore5ical approach based o nthe
underpinning rdbms theory may be a differnece in training. My engineering
trainginw as software and so I've got a good deal of softare tehory to fall
back on.  I approach circuit design by looking at what I can clearly see
and comprehend and then modify from tehre (my facvorite boosk in this
regard are the "engineers Notebooks' from Radi Shack).  I ma not an
engineer, so while the underlying theory of what I'm lookign at may be much
more flexible, i don't knwo how.

To me this is the differnece between a programmer and a software engineer.

Jeff kesselman
>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>
>
>
Jeff Kesselman
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net

-----BEGIN GEEK CODE BLOCK-----
     Version: 3.1
     GCS/CC/E/IT/MC d+(++)@ s: a C++++$ ULSC+++(++++)$ P++(+++)$ L++ 
     E--- W++$ N++$ o+ K--? w++(+++)$@>--- O+(++)>$ M+>$ !V PS++ PE+ 
     Y+ PGP- t+ 5+ X- R+(++)$>+++* tv+ b+>++ DI+++ !D G e++ h r+++ y+++
------END GEEK CODE BLOCK------ 

Speak Geek!
http://krypton.mankato.msus.edu/~hayden/geek.html