2

I have been looking into different database libraries for my online card game (PostgreSQL, Oracle, etc) and, while SOCI + pg or Oracle are much more powerful, they also are tricky to compile, integrate, and do a whole lot more than what I need to do.

Quite simply these are my requirements: Store the username, hash, wins, loses, email. Very simple.

The game itself will actually not communicate with the database that often. When the player logs in, I will log them in by retrieving the row by username, and verifying the hash with the hash generated by the password they enter.

Other than that, the server only accesses the database to add a user, record a win or loss after playing a round, or to update personal information.

Given that SQLite supports limited concurrency, this should be fine for my needs even if I have 100 or so card games running concurrently.

Reflecting on the above, is SQLite right for me or should I seriously think of opting for a more complex solution? Bearing in mind that databases are not my strongest point.

Thanks

mloskot
  • 37,086
  • 11
  • 109
  • 136
jmasterx
  • 52,639
  • 96
  • 311
  • 557
  • 1
    Why not use MySQL? It doesn't have the concurrency limitations and none of the "headaches" associated with the enterprise level solutions. Moreover, it's open source and could scale well to large numbers of games if you become popular. – tafoo85 Sep 28 '11 at 20:44
  • @tafoo85 Does MySQL simply allow me to execute SQL statements without needing to install additional software or is MySQL a server that runs on localhost? – jmasterx Sep 28 '11 at 20:49
  • MySQL can run and listen for connection on localhost only (see documantion for bind-address and skip-networking options) if you want to experiment you could also use libmysqld which is a C++ library providing MySQL as daemon, but that's discouraged for general purpose usage as it's complicated to use right. – johannes Sep 28 '11 at 21:25

1 Answers1

7

With that many clients SQLite is a perfect fit. However, I would recommend you wrap up this functionality in a simple and not database specific interface, and implement it for SQLite. Once you will get millions of clients along with concurrency/performance issues, you can simply throw in another implementation that uses more powerful database without changing your application code much.