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.


Meteor cost at scale will this become a major issue?
#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.