MongoDB embedding vs SQL foreign keys?

Question

Are there any particular advantages to MongoDB's ability to embed objects within a document, compared to SQL's use of foreign keys for the same logic?

It seems to me that the only advantage is ease of use (and perhaps performance?), and even that seems like it could be easily abstracted away (e.g. Django seems to handle SQL's foreign keys pretty intuitively).

Answer 1

This boils down to a classic question of whether to embed or not.

Here are a few links to get started before I explain some more:

• Where should I put activities timeline in mongodb, embedded in user or separately?
• MongoDB schema design -- Choose two collection approach or embedded document
• MongoDB schema for storing user location history

Now to answer more specifically.

You must remember the server-side usage of foreign keys in SQL: JOINs. Embedding is a single round trip to get all the data you need in a single document however Joins are not, they are infact two selections based upon a range and then merged to omit duplicates (with significant overhead on some data sets).

So the use of foreign keys is not totally app dependant, it is also server and database dependant.

That being said some people misunderstand embedding in MongoDB and try and make all their data fit into one document. Unfortunately this is re-inforced by the common knowledge that you should always try to embed everything. The links and more will provide some useful guides on this.

Now that we cleared some things up the main pros of embedding over JOINs are:

• Single round trip
• Easy to update the document in a lot of cases, unless you embed many levels deep
• Can keep entity data with the entity it is related to

However embedding has a few flaws:

• The document must be paged in to get it's values, this can be problematic on larger documents
• Subdocuments are designed to be unique to that entity that do not require advanced querying so you normally would not get two separate entities that are related together, i.e. a post could embed comments but a user probably wouldn't embed posts due to the query needs.
• Nesting more than 3 levels deep could effect your ability to use things such as the atomic lock.

So when used right MongoDBs embedding can become a huge power over SQL Joins but you must understand when to use it right.

Answer 2

The core strength of Mongo is in its document-view of data, and naturally this can be extended to a "POCO" view of data. Mongo clients like the NoRM Project in .NET will seem astonishingly similar to experienced Fluent NHibernate users, and this is no accident - your POCO data models are simply serialized to BSON and saved in Mongo 1:1. No mappings required.

Overall, the biggest difference between these two technologies is the model and how developers have to think about their data. Mongo is better suited to rapid application development.