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 track.
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 place. 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.
