[MUD-Dev] MUD Design Fundamentals (Was: Looking for
blprice at bedford.net
Fri Aug 29 17:40:30 New Zealand Standard Time 1997
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
> 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>
More information about the MUD-Dev