Advanced Topic - Doing it differently.

mrpotatohead at mrpotatohead at
Sat Apr 9 04:36:00 New Zealand Standard Time 2005

I've been sitting back and reading this thread for the last few days to
see how it played out, and honestly, I'm disappointed it degenerated into
bitching rather than some good discussion. So, let's try to get back on

I read the thread linked on the pitfalls of backing areas and rooms by a
SQL store and honestly, while some of the points are valid, there is no
reason you can't do it.  Data is a data, be it a pfile or an area file.

The real point in those threads is not that you can't run your mud off a
SQL store, but rather that there are various challenges unique to running
your area files in this manner.  Amazingly enough, most things we code
have challenges.  Strong programmers recognize challenges in systems they
are writing and make design decisions that mitigate them.  Remember, there
is no "right" answer, though there may be many "wrong" ones.

In particular, the load associated with keeping your rooms only in the DB,
querying everytime someone wants to move to a new room, and not caching
them in some fashion (RAM being the obvious place to do so) can completely
negate any of the potential gains from using a SQL store in the first

However, as an extreme, you could use your SQL store just during loading
of the mud (let's leave OLC out of this for now) and then there is
functionally no difference between having used a SQL store instead of a
file store.  The entire area structure has been loaded into memory at that
point, and the mud doesn't know the difference.

Now, I do not advocate using a SQL store in so limited a fashion, but as a
migration path, it's an important, early milestone.  But if you are to
move forward, then you can recognize more significant capabilities that a
SQL store can provide. However, this is where some of those other
challenges kick in.

The next most obvious challenge comes with OLC, and making sure that two
people trying to access the same room doesn't result in a damaged or
inconsistent state of the area.  Locking is one way to protect yourself
from this, but opens up the possibility of real time reads of that data
returning stale data, or worse yet, timing out.  This can all be dealt
with by careful planning of your OLC module, as well as choosing
appropriate levels of locking and integrating transactions.

At any rate, there can be very substantial gains from using a SQL store,
and those gains, like any, come with advantages and disadvantages.  But
there is no reason whatsoever that a proper design couldn't account for
all these considerations, and result in a very seemless transition to
using SQL rather than flat files.

ROM mailing list
ROM at
Unsubscribe here ->>>

More information about the MUD-Dev mailing list