[MUD-Dev] Re: Databases: was Re: skill system
jlangthorn at towertechinc.com
Wed Jun 24 09:18:29 New Zealand Standard Time 1998
> 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>
> > > > >
> > > > > Has any one tried using Orical or SQL to manage the data
> > > > >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
> I think we are not even on the 'completely levelless' band wagon
> > In order to succesfully map an object with dynamic runtime
> > 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
> > is designed in such a way as to implement object reflectivity
> > 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
> > 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
> 2) Objects who can change their properties at run time. (a rock can
> an intelligent rock on the fly)
> 1 maps nicely to a RDB because each of the objects compiled in simply
> 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
> 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
> Blob field. The problem is that the blob field then needs to be
> interpreted at run time, essentially recreating a large portion of the
> 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
for Characters, and areas and so on. My hope is to have the
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
picks up a new object his record simply gains a pointer to the
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.
if this seems a litle scrambled, it was writen on the fly so to
More information about the MUD-Dev