# Document Design Considerations

A question which is - in this author's experience - rarely asked is this: "How will this data be retrieved?" Customers give developers a list of information they want to capture, and designers jump immediately to "well, we could store this here, and that there..." instead of asking the next question - why? (or, more kindly, "to what end?") Most requests for data collection are not motivated by collection for collection's sake - _something_ is behind the request to collect data. Understanding how the data will be retrieved will give context to its collection, and will likely have implications for its storage.

## Recognizing Appropriate Relational Data

This will be a short section, as previous articles should have explicitly made the point that not all data is appropriate for a document model. If the importance of relationships between certain entities and other entities must never allow those entities to be out of sync, a document structure is not the best structure for those entities. Applying document design to relational data is a fool's errand.

## Designing Documents

Having eliminated scenarios where documents are not appropriate, let's design our documents to capture data which fits that paradigm.

### Repeated Data

Many many-to-one relationships in a relational database could be represented as an array of changes in the parent document. Returning to our hotel room example, the rental history of each room could be represented as an array on the room itself. This would give us a quick way to find who was in each room at what point; and, provided our keys lined up, we could also tell a customer which rooms we charged to their account, and for which dates.

The main question for this structure is this: what other queries against a room would we require? And, given how we could best answer these questions, is an array of reservations the best way to represent that? This is a key consideration for an array-in-document vs. separate multi-entry table decision. Adding a reservation, in an inlined array, is relatively trivial. However, which entity owns the reservation array? Are reservations based on the room, while related to the customer? Or, are they based on the customer, and associated to the room?

_(There is no right answer here; this illustrates the "considerations" portion of the discussion. People of good will, with different goals, may choose differently.)_

### Related Data

One theme, underlying all this discussion, is that data is related to other data. These relations are where our next decision point lies. Are these relationships optional? If so, do these optional relationships need to be defined by their presence, as opposed to their absence? Assuming a decision tree where all of the above are answered by "yes" - this relationship may be a candidate for a document property instead of a child-table relationship (with or without a foreign key).

We have alluded to a scenario for this type of data, but have not fully explored it up until now.