Designing a mongodb schema featuring a many-to-many relation

Question

Hi I've begun learning Mongo on a small home project to determine if its viable as a solution for one of our products at work. Before heading down the path I've dreamed up I wanted to run this by stack overflow to determine if this structure is sane and that data can be efficiently accessed n years from now.

The application is one that collects spreads for football games and allows users to place mock bets. This opens the door for all sorts of interesting analytics down the line from betting patterns to how spreads change over time etc.

• users
  • bets[]
• teams
  • standings[]
• games
  • away team{}
  • home team{}
  • bets[]

You'll notice from the list above I have bets listed twice. This is one of the big questions I have. Where would a doc that stores the game a user bet on be stored? In the games or in the users collection. Both make sense really. If I store it one vs the other than I have to query a big list in the other for showing the data. For instance if I have users.bets then I when I want to show all the bets for a given game I have to look for that game.id in all of users.bets and vice-versa. Is this efficient? Sane?

I guess this is a struggling point for me. I know how to deal with many-to-many in a relational database, but not here. Is a 3rd collection for storing the many-to-many still the way to go in mongo.

Opinions and reference material are welcomed.

Answer 1

There is nothing wrong with denormalizing data - if it gets queried in multiple places, then in your application it makes sense to store it in multiple places.

Things to consider when you are thinking how to structure things is what the data will look like in X months when there is a lot more of it.

If this application collects data for many years, it might be problematic to have all the bet history embedded in the user document - will you need all of their history every time you load their document? Or will most of it be useless and not relevant?

I would encourage you to consider storing data you need "together" together, but be realistic and critical about whether you will always need all of that data.