How to screw up your MongoDB schema design

Mongo has recently become a thing. Fortunately, some RDBMS skills port over easily -- but schema design isn't one of them

Page 2 of 2


While these more structural design principles are good rules of thumb, there is always an and/if/or/but. Remember that while document databases like MongoDB are usually not transactional in a manner similar to that of a relational database, they allow you to have atomic writes within a single document. There are times you may make a compromise from your object model in order to achieve atomicity. This means moving something that would be in another document into the same document as another thing you need to modify together. You may also use subdocuments in order to achieve this.

On the other hand, you may divide documents in order to achieve better distribution -- that is, shard more effectively. Sharding, if you recall, is where the collection of documents is distributed among server nodes using a hashing algorithm. If you are likely to use sets of subdocuments or document elements concurrently, you may find it's faster to divide them into separate shards, so they are distributed among more nodes and you achieve more parallelism on your read operations. In other words, sometimes you may need to break up something that more naturally fits in one document or subdocument in order to achieve better shard peformance.

What if you don't do that?

If you do a 1:1 table-to-document port of your RDBMS, you can expect the following:

  • Miss joins where if you'd have embedded documents you wouldn't
  • Lose atomicity
  • Do more operations
  • Gain little in terms of parallelism
  • Risk writing a ranty hate blog that makes you look ignorant or worse, like a crusty ol' PL/SQL developer or a DBA fearing for his cushy job maintaining triggers
  • Look like one of those hipster hackers who embrace every new technology but fail to use it correctly

To sum up, holy crap, a lot of people love Mongo! Schema design is the critical path to using MongoDB efficiently and effectively. Just as with your RDBMS, you may have to make compromises in order to achieve better atomicity or scale. Before you hate on MongoDB, you should at least make sure you're holding it right.

This article, "How to screw up your MongoDB schema design," was originally published at Keep up on the latest developments in application development, and read more of Andrew Oliver's Strategic Developer blog at For the latest business technology news, follow on Twitter.

| 1 2 Page 2