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

[##Make Nylander]

[Original message sent by s001gmu at nova.wright.edu]
| 
| 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.

	I'd say this is not inherent to a query language or RDB model
	per se, but rather to the implementation of a particular database
	engine. 

| Unless I misunderstand, a RDB uses reflectivity, just not as easily
| mutable reflectivity.  You can't just add a new variable on the fly... you
| would have to create a new table, identical to the last + one new column,
| and then transfer all the old data over, adding in the new variable
| somehow.

	You can do this quite easily in, for instance, MS DAO/Jet (Access) --
	TableDefs("TableName").Fields.Append "FieldName". DAO has
	pretty nifty scheme of organizing databases to collections of
	objects (a Database is a collection of TableDefs, each of which is
	a collection of Fields. A collection is, essentially, a linked
	list of objects). You can create and drop tables, fields and
	indexes run-time very easily. Access is not very efficient in
	physical storage management, but again, this is due to
	implementation (Access is a "flat file" database), not design. 

		MNy

--
I never regret my failures, but I regret every missed opportunity.