[edit] In light of the above post, which was made while I was typing, I think my advice falls flat.

I'm going to "fourth" the recommendation for SQLite. I'm using it in an application right now which has two to three threads accessing the database at a time. The database-wide locking is indeed a bit of a pain, but it really hasn't become a problem. I simply do all the processing of data that I need to outside of a lock, then begin a transaction and quickly shove in all the data I need to. SQLite is fast enough that I can enter ten or fifteen thousand rows into a 6-field table with 3 text-based indices in a fraction of a second, then commit the transaction and let others use the database.

All my threads can simultaneously read data from the database, and they all just have to take a little break when it's INSERT or UPDATE time. As long as you're taking care to do all your SELECT's and business logic before beginning a transaction, then only do database modifications inside a transaction, SQLite will fit the bill.

But then, it sounds like you've already tried it and sacked it. So good luck rolling your own--if it's better than SQLite, I want a copy :-)

Quote:Original post by Extrarius
Just thought I'd throw in that by "Stand-Alone" I don't mean it has to be source I can compile into the application, but rather that it shouldn't require massive server resources like Oracle and it'd be GREATLY preferrable if it was simply a dll or small program - the main issue is resource usage and freedom from complex installation. If it's light-weight and can be run immediately after extracting it from whatever archive format (and has any settings in a local config file of some sort such as ini), it'll do just fine.

Wouldn't Firebird [1] --- the former Interbase --- suit your requirements? I remember it offering "DB in a file" possibilities, and it is a full-featured RDBMS. It might be overkill for your needs though.

Personally I'd roll my own for something that simple, or I'd use (G)DBM, because storing (key, value) pairs is really what it's meant for. I don't know if (G)DBM is available on non-UNIX systems though, and GDBM is probably GPL.


Hope this helps.

[1] http://www.firebirdsql.org

Quote:
Essentially, it will be used to store pairs consisting of a "UserName" (a string) and "Credit"(fixed-point number, though storing it as double precision should be fine)

Unless you skiped a few details, you will not want to use any kind of database for that.

You will write a text file, with two columns. Name might be escaped, or delimited, and the value would be just a text representation of the number (leaving you the flexibility of changing formats).

When application starts, you will read the files, and put everything in a hash table. If you need remote access, add a simple socket protocol, with "get NAME" and "set NAME VALUE" options. And that, is your application.

Anything more for this purpose is a HUGE overkill. Unless of course, you will be having hundreds of tables and millions of records somewhere in the future, but for start, KISS.