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
扫一扫
902
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
