The main reason I mentioned using SQL based databases before is that you can query/insert/update your entire user base without having to open/close/edit hundreds or thousands of files.
For example: Imagine that you just released a patch to your game and found that a new "dupe" bug is present that lets people duplicate gold. You want to go through your player accounts and search out people who have more gold than normally possible (~600,000.)
#1 SQL Database solutionYou use your query editor and run the following:
select username from player_resource_info where gold > 600000;The query engine returns a list of user names that have over 600,000 gold. The entire query should take no more than a few seconds for a database of less than 1 million users (say, 1024 bytes worth of data for each.)
#2 Flat file/director solutionYou write a program that loads each account file, parses through it to the gold section, and then checks the value. If the person has over 600,000 you write it out to your list. Now imagine that you are trying to do this in "real-time."
As you can see, the SQL database makes this very easy to check. Not only can you perform selects, but you can also perform inserts, deletes, or updates based on criteria. I did not even talk about how you could use the transaction log capability to "go back in time" to find players who had a sudden jump in gold.
As for stability, I wouldnt worry about losing the whole player database. You should always have a safe backup system in place before ever going to production. I recommend that you plan your backup system from day one. You can also use the transaction log system to roll back the user info is something bad happens. And there is always SQL clustering and/or replication software. If you plan on load-balancing, you will definitely want to use a database oriented system with replication.
If cost is a concern then I suggest you look into MySQL or any other capable free database system. You can even use Access for prototyping. Once your game is ODBC ready, you can really use any database that can handle it when production time comes.
LostLogic
www.lostlogic.comAuthor, Multiplayer Game Programming