[MUD-Dev] Re: Databases: was Re: skill system

[jacob langthorn]

> On Sat, 20 Jun 1998, Jon A. Lambert wrote:
> 
> > On 16 Jun 98, s001gmu at nova.wright.edu wrote:
> > > On Thu, 11 Jun 1998, T. Alexander Popiel wrote:
> > > 
> > > > In message:  <9193945826E7D0118BB4080009DBF8F611737D at TTECH>
> > > >              jacob langthorn <jlangthorn at towertechinc.com>
> writes:
> > > > >
> > > > >	Has any one tried using Orical or SQL to manage the data
> base
> > > > >for the mud? If so what sorta luck did you have?
> > > > 
> 
	[jacob langthorn]  Deleted.......  
> > RDBs are ideal for mapping objects with static runtime attributes.
> 
> Bingo.  Not all of us are on the 'fully programable' band wagon.  In
> fact,
> I think we are not even on the 'completely levelless' band wagon
> either.
> 
> > In order to succesfully map an object with dynamic runtime
> attributes 
> > to an RDB, the object must be reflective.  That is it must be at
> > all times self-aware of it's attributes.  In addition the RDB
> ideally
> > is designed in such a way as to implement object reflectivity
> instead
> > of the object directly.  This requires an interface or translator 
> > module.  One can certainly map an object directly to an RDB 
> > using what static properties are known to all objects and putting
> the
> > dynamic properties into a binary blob.  
> 
> Let me attempt to restate the above, to test my understanding.  Please
> correct if I mess anything up.  :)
> 
> There are 2 kinds of objects (to generalize).
> 1) Objects whose properties are compiled in. (A rock is a rock is a
> rock)
> 2) Objects who can change their properties at run time. (a rock can
> become
> an intelligent rock on the fly)
> 
> 1 maps nicely to a RDB because each of the objects compiled in simply
> gets
> its own table, with one column for each property.  2 does not map well
> because the setup listed for 1 (one table per object, one column per
> property) will just not work as the properties themselves change and
> changing a table's layout in SQL is ... expensive ... to say the
> least.
> 
> One suggested solution to mapping 2 into a RDB is to map out the basic
> objects/properties as in 1, and then cram all the changeable ones into
> a
> Blob field.  The problem is that the blob field then needs to be
> interpreted at run time, essentially recreating a large portion of the
> DB
> layer in code (storing not only data, but how the data is used).
> This, in
> essence, defeats the purpose of using a RDB to begin with.
> 
	[jacob langthorn]  I think you are confusing tables with records
or I am.
	I was thinking of building a table with all the atributes of
objects, another 
	for Characters, and areas and so on. My hope is to have the
server track
	the relations, ie a character record points to the object
record's that the 
	character has picked up, as well as which area s/he is in. When
a character 
	picks up a new object his record simply gains a pointer to the
objects record
	record.Along this vein all objects have the abilaty to take on
all of the posible
	properties properties in the system, ie your rock would just
gain a flag in the
	colum for flying. the same would aply for characters and areas.
I appologieze
	if this seems a litle scrambled, it was writen on the fly so to
speak.

	Deleted.....

	Jacob Langthorn
>