Of disk swapping, database structure & project management..

[Jon A. Lambert]

> From: Greg Munt <greg at uni-corn.demon.co.uk>
> Subject: Of disk swapping, database structure & project management..
> Date: Thursday, May 01, 1997 4:03 PM
> 
> Has anyone experimented with swapping unused parts of the mud database to 
> disk, reading it back in when needed? What sort of format is it stored in 
> (eg binary, ASCII, etc)?

Yes!  Take a look a the COLD project for this in action.  It works remarkably
well.  Their DB is binary, with a compression option. It uses NDBM as
an indexing method,( a glorified? ISAM).  It also uses an object caching mechanism 
that implements reference counting and writing of dirty objects.  A backup 
mechanism is in place and works semi-asynchronously.   Recovery of a corrupted 
database is not for the faint of heart.  Practical use of the database by external
applications is not likely.  The DB can be decompiled and recompiled to ascii files. 
There are some good ideas here.  

I am working on similar ideas that involve integrating an object persistent store 
with a relational database.  I use a different approach to the DB design.  I map
object prototypes to a DB schema and object instances to records within that
schema.  Inheritance structures are mapped into one-way ( child ->parent )
associations with referential integrity constraints in place.   Normal object 
associations are navigable in both directions (similar to a double linked-list).
Method code can only be associated with an object prototype at this time and
is stored in an associated but separate schema.  Once my language design
matures this may not be the case.  The inheritance tree of the exposed objects
would best be described as wide and shallow.   Cold and LPC have much
deeper exposed inheritance structures.  The bulk of my inheritance structure is
embedded in the server and is accessed via "native" methods.  As a rule, if a 
given object is an abstraction it most likely is not exposed in my server.
Lest you think this means hard coded, this is not the case.  There exists a 
configuration DB that contains all the attributes of the abstract objects
(both implementation and policy details).  It is loaded at startup and never 
swapped out.  It is also generally static (rules of the game).  It can be edited 
online and refreshed online.


JL