There's often a bit of confusion, among new players and old, when concern is expressed over DB size on a muck. It would appear to only be a minor problem, with disk space being relatively cheap, and memory, while being moderately more expensive, easily worked around by the FB server's ability to swap unused items to disk. So, I thought it might be a good idea to put forth some basic facts about the muck DB to detail exactly why this is a concern.

One of the most basic facts some people miss about muck databases, or DBs, is that storage is linearly organized. Each object, room, exit, or program is assigned a slot, or dbref for DataBaseREFerence, in the DB when it's created, the lowest unassigned number. This means that each new object created goes at the end, increasing the size of the db by a measured amount. Assuming the building continues, so will the size of the DB grow, numbers rising upwards.

This would seem to be a natural state of affairs, and nothing to be concerned about. One expects building, and if something too large is built, or a host of frivolous objects with little to no use or substance, the use of the @recycle command can fix the problem yes? Well, yes and no.

The problem lies with the fact we've got objects in the DB that _have_ to know where other objects are, like programs owned by players, or even other players with referenced commands. Therefore, the dbref used to tell which object something is doesn't change as long as it exists, and space is always held in the db for it. However, then we come to the @recycle command.

It's @recycling. Not @removing. If an object was literally removed from the DB, there'd be a gap that lots of code would skip over, causing countless snarls. So, when you use the @recycle command, the number is assigned to an object of a type used to hold that dbref for the next object to need it, a garbage object. So the next time something is created, it gets that slot.

But garbage objects take up space still. And the number of slots never, ever goes down. So, if you build, and there are no garbage object slots for your object to take, you've increased the size of the muck db permanently, and moved it that much closer to problematic size. @recycling helps, yes, but 'tis much better to consider before building.

---------- This File is (c) 1995 by Crys Nievar Ri'i'des.
All Rights Reserved. Limited Permission is granted to transmit or receive this file electronically through a FBMuck or mail server. Users are requested to notify Crys if they post this file on a muck so updates can be mailed out.