I am a new comer to databases, however i think I finally possess a situation where flat files will not work.

I am writing a course to evaluate the final results of multiplayer games, where each game might have a variety of gamers arranged into a variety of teams. I wish to allow gamers can win, tie, or leave partway through the overall game (and win/lose according to team leadership).

I additionally may want to store historic player rankings (unless of course it's faster to simply recompute that using their game history), so I'm not sure in the event that means storing each player's rating alongside each game performed, or getting another table for every player, or what.

I do not use whatever criteria that impacts database choice, but I'll list the free ones:

I do not recommend an embedded database like SQLite, because embedded databases make trade-offs in features to support space &lifier size concerns. I do not accept their belief that data typing ought to be relaxed - it's result in numerous questions about SO about going to cope with date/time filtration, amongst others...

You will want to find out about normalization, getting data to 3rd Normal Form (3NF) since it makes sure referential integrity, that also minimizes data redundancy. For instance, your player stats wouldn't be saved within the database - they'd be calculated during the time of the request in line with the data onhand.

You did not mention any requirement for securing systems where multiple customers might be competing to create exactly the same data towards the same resource (a database record or file within the situation of flat files) concurrently. What I recommend is obtain a bestseller on database design and then try to understand normalization rules thorough. Disbursing data across separate tables possess a performance impact, they also impact the convenience-of-utilization of query construction. This can be a very including subject, and there is no simple response to it. This is exactly why companies hire database managers to have their data structures enhanced.

You might like to take a look at SQLite, should you prefer a lightweight database engine.

Good quality options were pointed out already, however i think that on Java platform, H2 is an extremely sensible choice. It is ideal for testing (in-memory test database), but is effective moreover embedded use cases so that as stand-alone "real database". Plus you can easily export as dump file, import from that, to maneuver. And works effectively too. It's produced by an excellent Java DB guy, and isn't his first take, and you will check this out from maturity from the project. On the top of the it's still being positively developed in addition to supported.

Try also OrientDB. It's free (Apache 2 license), run everywhere, supports SQL and it is fast. Can place 1,000,000 of records in 6 seconds on common hw.

A thing on why nobody even mentions the "NoSQL" databases when you used it as being a tag:

Non-SQL databases are becoming lots of attention (as well as outright hype) lately, due to some high-profile usecases, because they are new (and for that reason interesting), and since their commitment of incredible scalability (that is "sexy" to developers). However, merely a very couple of very large gamers really need that type of scalability - and also you certainly don't.

Another factor is the fact that SQL databases need you to define your DB schema (the dwelling of tables and posts) in advance, and altering it's somewhat problematic (particularly if you already possess a large database). Non-SQL databases tend to be more flexible for the reason that regard, however, you pay for this with increased complex code (e.g. once you introduce a brand new area, your code must have the ability to cope with elements where it's not present). It does not seem as if you need this type of versatility either.