[MUD-Dev] Databases (was Re: Commercial-use Restrictions on Code Bases)

cg at ami-cg.GraySage.Edmonton.AB.CA cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Jan 16 10:04:48 New Zealand Daylight Time 2000

[Charles Hughes:]

> At the risk of being slapped by a mackerel, who here really thinks they
> can do a better database design than those afforded by the likes of the
> free or commercial databases?  [I'll ask those here who've actually
> worked on these databases not to chime in. :)]
> It seems to me that segregating the database issues and then simply using
> a database is far better than creating a new one.  This would change
> the "databases/memory management" division above into two divisions -
> database usage, memory management.
> Yes? No?

You are ignoring the issue of the appropriateness of commerical or other
standard databases. Calling the persistence back-end of MUD system its
"database" is handy, in that it describes it in one word that has a lot
of the right meaning. That does not mean, however, that the way that
backend works is anything like the ways a normal database works.

This was discussed not that long ago, I believe. The inappropriateness
of standard databases is one reason many MUD authors create their own.
For example, my "database" has no concept of "tables" or "rows". It
simply associates a hunk of saved data with a key, and provides automatic
means for saving/restoring such data, and provides an efficient caching
mechanism for the hunks of saved data. Some of the hunks are strings,
some are arrays of integers, some are compessed hash tables, etc. They
vary wildly in length and in internal structure. I have no idea how to
use a standard database to store such things anywhere near as efficiently
as my custom "database" does. From the other direction, the nice indexing
and searching facilities of normal databases are of very little use to
my MUD system.

There has been discussion of using normal databases as MUD backends, but,
to me, it seems a lot like working very hard to use a hammer and pliers to
work with screws.

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

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list