1

I am building an e-learning app, and showing student activities as a timeline, should I embed them in the user collection, or create a separate collection with an userId.

Constraints:

  • One to many relationship.
  • User activities are detailed and numerous
  • For 90% of the time, we only need to see one user at an time, the other case is where a supervisor(teacher) needs to see an summary of the activities of users(maybe another collection?)
  • I haven't thought of the use case of searching for activities and finding students, maybe I'll have a use for this later on? (eg. see who finished some particular activity first? But that changes the relationship to be Many to many and is a completely different question)

I have found different schemas for the related problem in these two questions:

Community
  • 1
  • 1
TiansHUo
  • 8,509
  • 7
  • 45
  • 57
  • 2
    "Try to embed as much as possible" is bad advice. Have reasons for embedding - and have reasons for not embedding. Your case seems clear cut - do *not* embed. – Asya Kamsky Nov 29 '12 at 03:20
  • I have read many questions here on SO, and suggesting embedding seems to be the norm. Could you give a more detailed explanation on why in this case `activities` shouldn't be embedded? – TiansHUo Nov 29 '12 at 05:35
  • there is nothing wrong with embedding per se. "Embed as much as possible" with no caveats is bad advice because it doesn't consider any use case nuances that might make it a bad idea to embed. "User activities are numerous" suggests your documents might get bloated if you embed activities. You also have to consider the use case where teacher may be querying across activities of all students (hard when they are embedded). Etc. etc. – Asya Kamsky Nov 29 '12 at 20:37

2 Answers2

2

Both of those articles are right and both are wrong.

To embed or not to embed? This is the always the key question and it comes down to your needs, querying and storage and even your working set.

At the end of the day we can only give pointers you can't actually tell you which is best.

However, considering the size of an activities feed I personally would not embed it since it could easily grow past 16meg (per user) however for the speed and power of querying you could aggregate, say, the last 20 activites of a user and then embed that into the users row (since the last 20 is normally what is queried the most).

But then embedding an aggregate depends, sharding can take care of querying huge horizontally scaled collections and using the right queries means that you don't gain any real benefit from embedding and could potientially make your life harder by having to maintain the indexes, storage and queries required to maintain that subdocument.

As for embedding to the point of death. A lot of MongoDBs querying at the moment relies mostly upon one or two level embedding so that is why it could get hard to maintain say 12 nested tables, at which time you start to see questions on here and the Google group of how to maintain such a huge document (answer is client side if you really want to).

For 90% of the time, we only need to see one user at an time, the other case is where a supervisor(teacher) needs to see an summary of the activities of users(maybe another collection?)

Considering this I would house an aggregate on the user which means the user can see their own or other users activity singulary with one round trip.

However considering that a teacher would have to most likely have pages results from all users I would house a separate activities collection and query on that for them. Paging an aggregate of subdocuments requires a few queries and in this case it would be better to just do it this way.

Hopefully that should get you started.

Sammaye
  • 43,242
  • 7
  • 104
  • 146
1

You should not embed activities into student document.

The reason I'm pretty confident of this is the following statements:

"User activities are detailed and numerous"
"showing student activities as a timeline"
"teacher needs to see an summary of the activities of users"

It is a bad practice to design schema that has ever-growing documents - so having a student document that keeps growing every time they complete/add another activity is a recipe for poor performance.

If you want to sort student's activities, it's a lot simpler if each is a separate document in an activity collection than if it's an array within a student document.

When you need to query about activities across multiple students, having all activities in a single collection makes it trivial, but having activities embedded in student documents makes it difficult (you will need aggregation framework, most likely, which will make it slower).

You also say you might have need in the future to "see who finished some particular activity first? But that changes the relationship to be Many to many and is a completely different question" - this is not the case. You do not need to treat this as a many-to-many relationship - you can still store multiple activities associated with a single user and then query for all records matching activity "X" sorting by time finished (or whatever) and seeing which student has lowest time.

Asya Kamsky
  • 41,784
  • 5
  • 109
  • 133