how to design MongoDB schema

Type of query: ask yourself what could be the best model representation for the most frequent queries you'll need     to do. Everytime I'll get the parent document I'll always (or really often) need all the child documents. Answer    : Nested.

  2 Data model lifecycle: think about the life cycle of the container document and its content: make sense that child     documents will still have to exist when the parent document is deleted? If the answer is "no" nested is the way.

  3 Snapshots: another reason that should affect your choice is the data you're representing and if the nested item i   s a snapshot of something happened at a given time. Suppose you're working with a "Receipt" object that contains    a list of buyed products these will be copied as a nested documents in the receipt. You're storing an information     related to a specific time like the product cost. So if your child documents are snapshot, pick a nested represe    ntation.

  4 Direct access: how many times you need to easily access the nested document (without caring of its container). If     you need this, go for a flat design with references.

  5 Number of nested object: a MongoDB document has a size limit of 16MB (quite big amount of data). If your subcolle   ction can growth without limits go flat.

  6 Rule of thumb: if the amount of data to transfer doesn't affect your client experience and the number of subdocum   ents has a numerical limit, go nested, otherwise flat.

  7 Embedding is better for...

  8 Small subdocuments

  9 Data that does not change regularly

 10 When eventual consistency is acceptable

 11 Documents that grow by a small amount

 12 Data that you’ll often need to perform a second query to fetch Fast reads

 13 References are better for...

 14 Large subdocuments

 15 Volatile data

 16 When immediate consistency is necessary Documents that grow a large amount

 17 Data that you’ll often exclude from the results Fast writes