Document Database Data Modeling

Document databases model data around aggregate documents and application access patterns rather than normalized relational tables. The key design decision is whether related data should be embedded in one document or kept in separate documents and linked by identifiers.

A document database stores records as documents, commonly using a JSON-like structure. A document can contain nested objects and arrays, allowing related data that is commonly read together to live in one aggregate. This differs from relational modeling, where related information is typically split across normalized tables and reconstructed with joins.

The starting point for document modeling is usually the application's access patterns: what data is read together, how it is updated, and which queries must be efficient. If an application normally retrieves an order together with its line items, embedding those items in the order document can make that read straightforward.

Embedding is useful when the child data belongs naturally to its parent, has a manageable size, and is usually accessed with the parent. Referencing is more appropriate when related data is large, shared by many documents, independently updated, or needs its own query lifecycle. The choice is therefore a trade-off rather than a universal rule.

Document models also require attention to document growth and update behavior. Frequently changing or unbounded arrays can make embedding problematic, while excessive references can recreate the complexity of relational joins. A good model keeps common operations simple while respecting the database's document-size and indexing constraints.

Key points

• Design documents around aggregates and actual access patterns.
• Embed data that is closely owned by and commonly read with its parent.
• Use references for large, shared, independently managed, or unbounded data.
• Avoid unbounded embedded arrays and uncontrolled document growth.
• Denormalization can improve read performance but may introduce duplicated data and update work.

Interview questions

How would you model an order and its line items in a document database?

If line items are normally retrieved with the order and belong specifically to that order, I would usually embed them in the order document. This makes a common order-read operation a single document lookup. I would also consider the maximum number of items and whether the array can grow without a practical bound. If those constraints make the document too large or difficult to update, I would consider storing items separately.

What is the difference between embedding and referencing in a document database?

Embedding stores related information directly inside a document, while referencing stores the related information separately and keeps an identifier to connect it. Embedding is convenient when data is tightly coupled and commonly read together. Referencing is useful when data is shared, independently updated, or potentially very large. The choice should follow the application's access and update patterns.

Why should access patterns influence document design?

Document databases are often designed to make important application reads efficient without reconstructing normalized relational structures. If two pieces of information are almost always retrieved together, placing them in one document can simplify the operation. Conversely, data that is queried or updated independently may be better separated. Therefore, the same business entities can legitimately have different document structures depending on how an application uses them.

What problems can excessive denormalization create?

Duplicating data can make reads simpler, but the same value may then exist in several documents. When that value changes, every relevant copy may need to be updated. This increases consistency and write complexity. I would denormalize deliberately, based on important read patterns and acceptable consistency requirements, rather than duplicating data automatically.

How would you handle a relationship where the child collection can grow without bound?

I would be cautious about embedding an unbounded collection because the parent document can become excessively large and increasingly expensive to update or retrieve. I would consider moving the growing records into separate documents, potentially partitioning them by parent and another useful key such as time. The exact structure should reflect the application's queries and retention requirements. I would also consider whether the relationship is truly owned by the parent or is independently managed.