Advice for modeling a database for multiple games

I have multiple games I want to store data for. The data for each player is stored in a single document with a UUID to identify it. The two options I have thought of so far is:

  1. Have one collection per game.
  2. Have one collection for all games.

The problem with option 1 is that I do not know how I would get all stats for all games per player while having good performance. Sending a query to each collection simultaneously to get all their stats seems wrong, although I think this is the best option so far.

For option 2, I would not be able to create indexes on the fields that needs to be indexed because the number of games and fields per game could be expanded at any time. It would also be very many read and write operations on a single collection which seems very wrong.

Does anyone have any advice on this?

Hi @Henrik ,

Having a collection per game doesn’t sound right. We have a known antipatterns of having to many collections and indexes and we should avoid it as much as possible.

The MongoDB locking is per document so writing similar objects to the same collection should not interfere with concurrency as long as you hit different documents.

Additionally, as your database grow and you wish going to sharding the deployment having single collection to be sharded makes more sense than lots of small ones which doesn’t.

You might consider having a hybrid solutions if the single collection doesn’t work like collection per month or per 6 months for all games.

Now if you have a large number of attributes that you need to index for search you may consider the attribute pattern for each game

I suggest reading the following articles


1 Like