Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think this is a design discussion that is probably best done live, but hopefully, I can steer you in the right direction. </p> <p>It sounds like there are 3 main entities involved in this scenario: Customers, Deals, and Deal Bidding History. The decision to embed vs. storing data in separate collections is a design decision specific to the developer's app. I highly recommend to take the free online training course if you haven't to learn some of the basics. There is a lesson on basic schema design that will help guide you in the thought process. It looks like you already intuitively know how to make the decision as you are considering your main data access patterns.</p> <p>Based on my understanding of your data, I would probably store your customer data in it's own collection. The reason being is that your app will probably access customer details independent of deals, and it doesn't appear there is a need to access customers and deals in an atomic way (Mongodb is designed to provide atomic operations at the document level). These are some reasons why duplicating customer data across all your data probably isn't the better choice. Once a customer logins, you pull customer data, and you have the context (ie. customer id). You can then use this context to read and update the deal information. Your deals collection actually looks good. With customer id, you can then pull out a deal, as well as various branches of deals (there's some references to tree design patterns on www.mongodb.org if you want to reference them--note that your design pattern does match the standard quite closely). There is one danger of embedding deal history into a deal though. Note that there is currently a 16MB limit on a single document. If you keep the deal history subdocuments lean, you should be able to store alot of history; however, if your app is like a micro bidding app then the 16MB limit may pose a problem; if this is the case, then you will need to store deal history records into individual documents in another collection. If it make sense, you may choose to store some redundant data in your deals such as the last 10 bids if it makes reads easier on your app (vs. the possibility of having to update multiple targets). In any case, embed if it is reasonable as it will provide your app simplicity and faster data access.</p> <p>Also, if you end up embedding deal history into your deals, your documents will grow in size with every document. MongoDB stores documents contiguously on disk for fast updates in place and reads. The implication is that if documents grow beyond it's current allocated space, MongoDB will move the entire document to another location on disk. This can slow updates down, and maybe of concern if your application is heavy on updates. To prevent untimely document moves, look up on using the padding factor option and "powersof2" setting on the mongodb.org website.</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing MongoDB Collections vs Indexing
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDylan Tong
    1. USDylan Tong
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COVery informative. I did not know of the 16MB limit on document size - that may potentially be a problem for me. Thanks a ton!
      singulars
      1. PO
      1. USgone
    2. COAlso, thanks for the "powersof2" setting reference - looks like it'll be usefull
      singulars
      1. PO
      1. USgone
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload