1

I come from a relational database background and am still trying to get my head around how to store data that would have been relational in a NoSQL database (or JSON object).

My question is, how would I store data about villages? Each village has a user attached to it, and each village has an X and a Y coordinate. This is what the object might look like:

var map = [{
  x: 1,
  y: 1,
  terrainType: land,
  village: {
    mayor: jragon,
    population: 150,
    gold: 100,
    iron: 25,
    garrason: {
      archers: 4,
      knights: 1
    },
    buildings: {
      smith: {
        level: 4,
        upgradeFinish: false;
      },
      mill: {
        level: 2,
        upgradeFinish: 'some date/time...'
      }
    }
  }
}];

However, as you can probably see it might get a bit out of hand. I guess using some of the mongoose helpers might help when querying for data.

Even with this object there is still some aspect of relation. map.village.mayor refers to a User in a different collection.

The map collection is used to draw the map each time. When drawing the map it decides what tile to use by what level the village is.

Sorry if I haven't made myself clear!

Jragon
  • 45
  • 9
  • 1
    There's nothing fundamentally wrong with your design. The mayor would typically be stored as the ID of a document in the "people" collection, although to avoid the necessity for "join"-like operations and multiple DB accesses, or special queries, some information necessary about the mayor might also be stored directly in the village table. –  Dec 13 '14 at 16:46
  • Okay. Say you wanted to find all the villages linked to a user. Typically you would join the villages table on user_id. But here would you search for objects where map.village.mayor = user_id? Is it best to have 3 separate collections; users, map, and villages? Then do a psudo-join command? – Jragon Dec 13 '14 at 16:51

1 Answers1

2

To have a good schema design in MongoDB, you should really care about the requests you will do frequently.

There are multiple things to take in mind:

  • Your requests should be correct regarding the limits of MongoDB (no transaction, document level atomicity, no real join...)
  • Your requests should ideally be simple to code.
  • You should be able to use indexes the right way. If each request can use an index to read the data you nead and not a lot more, then you've done a good job.
  • The name of the keys are duplicated in each document. You may shorten the names, but I'd rather do it automatically or not at all.

If you want to learn, I'd suggest you at least half of the book "MongoDB Applied Design Patterns" by Rick Copeland. Your question and the context may be too broad to even fit on stackoverflow.

dotpush
  • 428
  • 3
  • 14
  • common sense is not so common. – Gabe Rainbow Dec 14 '14 at 03:07
  • @Gabe Rainbow: I'm not sure for the translation of what I tell in this comment, but I tried to learn the lessons of someone who said something like "I goes without saying but it goes better with saying it" ;) – dotpush Dec 14 '14 at 03:18
  • @Gabe Rainbow: And I just missed that ["common sense is not so common" is idiomatic](http://en.wikipedia.org/wiki/Wikipedia:Common_sense_is_not_common) in English. Definitely a proof of what you said! – dotpush Dec 14 '14 at 03:24
  • hehe. basically im saying excellent if not near perfect answer. – Gabe Rainbow Dec 20 '14 at 03:51