Re: game db

> Several servers might be used to balance the load, so I might have from 1-3
> servers connected to the database at once. The clients won't have any
> direct connection to the database.

This architecture lends itself to an RDBMS like postgresql. You can connect
from several different computers to the same postgresql database, which is
what it sounds like you're interested in. MySQL is also capable.

>
> Its important to avoid data-corruption of the database, but I won't
> need the fullblown fsync option I believe. If the gamestate goes back
> 5 mins on crashes, that won't be a huge problem, as long as the data
> is consistent.

Postgres allows either option, as do many other databases.

> I haven't looked into SQL databases much, but I don't think I need much
> "fancy" features - I guess a basic SQL interface is plenty - doing simple
> selects and updates.

The main reason I like postgres is because of how it handles complex
situations gracefully. It doesn't sound like you really need a lot of complex
capability.

> Whate exactly are the prime differences between an embedded database and
> the full RDBMSs ?

An RDBMS is a seperate daemon running that accepts requests from an
application (i.e. your game) and returns a result to your application.

An embedded database can be considered a library of functions that are used
to securely maintain your data in a way that keeps it accessible. The
functions operate inside your application. A simple embedded database would
be to just write your data to a text file when you called a store() function
and read it back when you call a retrieve() function (that is obviously a
*very* simple form). Berkeley DB is a very good embedded database, with
transactions and good locking and everything else that would help you
maintain consistant data. Embedded databases have a much faster startup time,
since it doesn't require starting up a new process (like postgres does).

Here is my impression of what you need: a way to essentially save your
current RAM state (at least the relevant parts of the RAM) in case you want
to restart from that point. I would say that Postgres is probably overkill
for that. It sounds like an embedded database like Berkeley DB
(sleepycat.com) is what you're looking for, since it would be fast and
simple. To address the need for multiple servers accessing the data, you may
look into something like NFS. If you can come up with some reasons that
something like an RDBMS might be helpful, you should look into it, but it
seems more like you just want to store/retrieve current information in a
simple way.

Regards,
Jeff