3 ms·
If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might thin
by breischl 10y ago
If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column."
eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense.
Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy.
Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.