Thought Experiment: Using MySQL for working memory

Several friends of mine have recently expressed interest in creating a new MUD project. MUDs are kind of neat, especially for developing and testing game design and balancing principals, but are generally not commercially useful or very good at retaining value in the long run. However, they do sometimes give rise to a few interesting programming / implementation questions.

Recently I've been wondering if MySQL might be useful for creating a virtualized shared working memory subsystem to replace RAM and flat files in the context of a MUD. Let's consider a typical data structure.

MUDs consist of worlds made up of MOBiles, Players, Objects, and Rooms. Let's consider a Room. Rooms can contain Players an Objects (on the floor) as well as Mobs and room programs. These associations are typically stored as null terminated doubly-linked lists of pointers in memory. If the mud crashes, all of the data which has not been written to one of the flat files that store the players, rooms, etc is lost when the memory is purged. Further, building any kind of redundant or load balanced system is a challenge without having to rebuild the entire architecture of the system.

If, however, a MySQL database were used to store all of this working memory information, crashes would become less painful, parallelization would become easier, tool development would become easier (interface with the database rather than the MUD application) etc. What would be the drawbacks? Obviously performance, loss of control over validation (it's never good when validation code is replicated in more than one part of the system) the potential for invalid states to rise in an effectively persistent memory (the database) leading to a greater chance of data corruption, and the lack of a sane method of event based updates to the data. That is, an event recorded on one system in a parallelized environment may update the data that all of the other nodes would be referring to, but without any of the associated triggers in terms of data to send to connected players.

This then regresses into consideration of an event system configured in a shared memory environment (again, a database could be adapted to this purpose) but then raises the question of which system should be the one to write to the memory, causing a fallback onto a required elected master/slave failover system which has potentially wiped out any complexity savings that previously seemed apparent in using the MySQL database for parallelization in the first place.

So what value is there in the conclusion of this thought experiment? For one, it doesn't seem to make sense to hammer the square MySQL block into this round parallelization issue hole. I for one still wonder if it would be possible to design a subsystem that would achieve some of the desirable features of such a shared memory subsystem using MySQL as the backend datastore. However the point is ultimately moot as the performance of such a system would be so miserable as to be impractical. There already exist a plentitude of solutions for this problem all of which are probably superior to using a shared relational database for virtualized shared memory.