There is no single correct translation. The right pattern depends on how the application reads and writes the data. NoER’s catalog follows MongoDB’s data modelling guidelines.
| Pattern | Use it when | Watch out for |
|---|---|---|
| Embedding | The data is read together, the embedded side is bounded, and updates happen together. | Large documents; costly independent updates; duplication when embedded data repeats. |
| Referencing | The related data grows or changes independently, or is not always read together. | An extra lookup, joins in the application. |
| Extended referencing | A few fields of the related document are read often, the rest rarely. | Copied fields can become stale and need synchronization. |
| Subset | The related set can grow without bound, but only recent or frequent items are usually needed. | Keeping the subset and the full collection in sync. |
| Bucket | Append-only time series, queried as ranges for one owner. | Buckets must be bounded; summaries need updating on every write. |
| Tree | Hierarchies modelled with a recursive relationship, such as categories. | Moving a subtree may require several updates. |
Rules used by guided selection
When the container participates with maximum cardinality 1:
- All fields needed and the data rarely changes → Embedding.
- All fields needed but the data changes often → Referencing.
- Only some fields needed → Extended referencing, or embedding when the relationship is one-to-one.
When the container participates with maximum cardinality N:
- Only some related documents needed per container → Subset.
- All or most documents needed, with all fields → Referencing.
- All or most documents needed, with only some fields → Extended referencing.