Is arbitrary object keys within an object considered bad practice?

1

So let’s say I have a user that looks like this:

{
  _id: "1234",
  battletag: "Bob",  // replaces username
  emails: [],
  games: {
    overwatch: {
      characters: {
        Hanzo: { rank: 3 },
        Mei: { rank: 1 }
      }
    },
    world-of-warcraft: {
      characters: {
        corvid: { rank: 1 }
      }
    }
  }
}

My question is: Is this bad pattern? Before, I had these as lists but it made updating it nearly impossible, partially because if you have nested lists you can’t update them without some very irritating aggregations.

2

Split that up into multiple collections!

Which containin documents indexed by user ID

User ( login info + id) --> UsersGameData(id + User.id + GameTitle/ID + { nested game data here} )

In a traditional RDB I would have another so called pviot table which just had
User --> UserGames(User.ID, GameData,ID) --> UserGameData(id, nestedData)
It might very well be advantageous to have separate Overwatch and WorldOfWarcraft data collections if they get pretty specific/differ greatly/or performance becomes an issue. But, from the example you give it seems that the different games have very similar data structures which sounds like it would my first suggestion a good idea.

Seriously suggest you go lookup Relation Database Design. You’re using mongoDB which is NoSQL. That comes with a lot of freedom, but that doesn’t mean you can’t benefit from opinionated data structures.

Also, I highly suggest not using map/object/associative array keynames which contain -or any other special characters. Because this breaks dot notation (ie User.games.overwatch vs User.games.world-of-warcraft would think you’re trying subtract of from user.games.world) my rule of thumb is if I cant make a variable with that name, its probably not a good idea

Good: https://stackoverflow.com/questions/1661197/what-characters-are-valid-for-javascript-variable-names
Bad: https://mathiasbynens.be/notes/javascript-identifiers-es6 (it works, but is a huge pain in the ass :stuck_out_tongue:

3

But I thought the goal of using mongodb was to denormalize?

4

It sure is! Doesn’t mean that it’s necessarily a good idea to keep the data all in one place/unorganized. That gets too messy too fast! Not to mention how hard it would be to key/optimize queries for complex, differing document structures.

All NoSQL implies is that you don’t need to use traditional cookie-cutter datastructures, which is awesome but does require some consideration.