[MUD-Dev] Re: Databases: was Re: skill system
thenewt at use.usit.net
Wed Jun 24 09:31:10 New Zealand Standard Time 1998
[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
| 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
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.
I never regret my failures, but I regret every missed opportunity.
More information about the MUD-Dev