[MUD-Dev] MUD Design Fundamentals (Was: Looking for
jeffk at tenetwork.com
Fri Aug 29 14:48:33 New Zealand Standard Time 1997
At 02:26 PM 8/29/97 PST8PDT, you wrote:
>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.
>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
>> 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
>Brian Price aka Delver <blprice at bedford.net>
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net
-----BEGIN GEEK CODE BLOCK-----
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------
More information about the MUD-Dev