Should databases be used for realtime access, or should all player accounts be stored in memory of world server for fast access? Accounts will definately be stored in database regardless, because I need somewhere to store information about a player when it's not online. ;) Also, is there a middle ground here? If database is on a separate machine from the world server (which it should be), is it a good idea to maybe cache player accounts in text files on the world server?

I'd say it depends. If the information is disposable, like position or health or whatever; probably not. But if its important like sales or bank accounts, I'd say it might be a good idea. Just depends on how critical the information is I guess and how often you need to access it.

Your accounts information can probably be stored efficiently enough on a central server.

Game-relevant information (inventories / character stats) should be stored on a database server that is part of the same local cluster. This should be used for persistence if the cluster is isolated.

Time-critical information (stats for combat etc) should be cached and/or preloaded when needed.

Database access is always going to be slower than RAM access (and probably slower than file access, unless your file IO thread is swamped), so you have to make your decision based on whether the task needing the data is time-critical or not, and whether a small amount of lag can be accepted by your players to do the task (eg completing a trade can be expected to have a slight delay, making combat decisions can't).

I would not cache player account details in a text file. The problem with that design is that you have murky authority of the data. If for some reason customer service needs to change some property of the player account ("can go into premium zone" for example), then they'd have to both change the database, AND find all cached copies on world servers.

However, you don't want to store real-time data in a database, so you have to have some mechanism of migrating authority between the database and the world server for some pieces of the data. One way is to define what pieces of data are needed on the world server, and store the location of the data in the database. Put an application server in front of the raw database. When your application server gets the request "update property X" it will go to the database, see where the authority of the data is; if on a world server, contact that server and tell it to change the data.

I would only store "checked-out" data in RAM, not cache it in files. If a world server crashes, all checked-out data must be released back to the database. This is easiest done by having the database keeping a persistent TCP connection to the world server, and when the connection goes out, clear the checked-out field of all data on that server. Also, if the database server crashes, you'd need to find a way to re-sync the ownership state -- or flush it all, and notify all world servers that they need to re-acquire ownership.

(Note: when I say "database server" I pretty much mean "application server" that gateways to an actual SQL database -- I wouldn't recommend talking straight to the SQL from multiple places).

If you don't have a solid ownership semantic, then you may get into problems where the world server periodically writes data to the database, overwriting changes made by other systems (customer service, other world servers, etc) -- because of bugs or network intermittencies, you may even end up with two dueling world servers!