Is arbitrary object keys within an object considered bad practice?

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.

Split that up into multiple collections!

Which containin documents indexed by user ID

User ( login info + id) --> UsersGameData(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 vs would think you’re trying subtract of from my rule of thumb is if I cant make a variable with that name, its probably not a good idea

Bad: (it works, but is a huge pain in the ass :stuck_out_tongue:

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

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.