When should we consider representing a one-to-many relationship in an embedded collection instead of separate collection?

Question

Options

• AWhen the many is not very large
• BWhen the many is very large
• CAlways
• DNever

• A
  93% (51)
• B
  2% (1)
• C
  4% (2)
• D
  2% (1)

Explanation

Embedding a one-to-many relationship works best when "the many" side is small and bounded - for example, storing a handful of addresses or phone numbers directly inside a user document. This keeps related data co-located, reducing the need for joins and improving read performance. B is wrong because embedding a large collection (thousands of items) bloats documents, hits document size limits (e.g., MongoDB's 16MB cap), and degrades performance. C is wrong because unbounded or frequently updated sub-documents are better served by a separate collection with a foreign-key reference. D is wrong because embedding is a legitimate and often preferred pattern when the data is small and always accessed together with the parent.

Memory tip: Think of "embedded = envelope" - you only stuff a few things in an envelope; too many and it tears. If the "many" could be large or grow without bound, use a separate collection and reference it instead.

No community discussion yet for this question.