MongoDB schema embedding and nested unique keys

Question

I have a relational SQL DB that's being changed to MongoDB. In SQL there are 3 tables that are relevant: Farm, Division, Wombat (names and purpose changed for this question). There's also a Farmer table which is the equivalent of a users table.

Using Mongoose I've come up with this new schema:

var mongoose = require('mongoose');
var farmSchema = new mongoose.Schema({
    // reference to the farmer collection's _id key
    farmerId: mongoose.Schema.ObjectId, 
    name: String, // name of farm
    division: [{
        divisionId: mongoose.Schema.ObjectId,
        name: String,
        wombats: [{
            wombatId: mongoose.Schema.ObjectId,
            name: String,
            weight: Number
        }]
    }]
});

Each of the (now) nested collections has a unique field in it. This will allow me to use Ajax to send just the uniqueId and the weight (for example) to adjust that value instead of updating the entire document when only the weight changes.

This feels like an incorrect SQL adaptation for MongoDB. Is there a better way to do this?

score 2 · Answer 1 · edited May 23 '17 at 12:24

In general, I believe that people tend to embed way too much when using MongoDB.

The most important argument is that having different writers to the same objects makes things a lot more complicated. Working with arrays and embedded objects can be tricky and some modifications are impossible, for instance because there's no positional operator matching in nested arrays.

For your particular scenario, take note that unique array keys might not behave as expected, and that behavior might change in future releases.

It's often desirable to opt for a simple SQL-like schema such as

Farm { 
  _id : ObjectId("...")
}

Division {
  _id : ObjectId("..."),
  FarmId : ObjectId("..."),
  ...
}

Wombat {
  _id : ObjectId("..."),
  DivisionId : ObjectId("..."),
  ...
}

Whether embedding is the right approach or not very much depends on usage patterns, data size, concurrent writes, etc. - a key difference to SQL is that there is no one right way to model 1:n or n:n relationships, so you'll have to carefully weigh the pros and cons for each scenario. In my experience, having a unique ID is a pretty strong indicator that the document should be a 'first-class citizen' and have its own collection.

MongoDB schema embedding and nested unique keys

1 Answers1