[MUD-Dev] The grass is always greener in the other field

[cg at ami-cg.GraySage.Edmonton.AB.CA]

[Bruce Mitchener, Jr.:]

> I think that this problem (storage of objects that are being hoarded or
> otherwise stored away, outside of common day-to-day usage) can be solved on
> the technology side of things.  This is surely a problem for a system that
> attempts to load the entire DB into memory.  A disk-based system wouldn't
> have this problem.  However, a disk-based system in the tradition of
> Cold/Genesis would still have the problem with large backups due to the
> monolithic nature of the database.

Following up on the technological solutions...

How big are typical objects in UO? If they are under, say, 50 bytes, and
it is just the huge quantity of them that is a problem, then my suggestion
here won't help. However, if the objects are large, because they inherit
(and store) properties from ancestors, then my suggestion is this: have
the object only store properties that are different from those stored
on generic representatives. Have them then refer to those generics for all
the rest. Now, this is a major change in data representation, and trades
space for property-lookup-time, so if CPU time is already swamped, this
won't work. Those who have been here for a while will recognize that this
is essentially what I do in my DB, so we have at least one example of
this working.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev