This is a fairly high level question as I am in the initial stages of planning this application, and am also very new to MongoDB and document-based databases in general. Disclaimer aside, I am building a to-do list type application whose two main types of data are users and items (aka tasks or todo's), and my question is, what would be a good way to structure this data in mongodb, if I want it optimized more for read speeds rather than updates?
My initial thought, based on my limited knowledge of mongodb, is that since it allows embedded type data structures I could basically store it in a single collection like this:
{
username: "joe",
password: "...",
items: [
{
text: "This is a task",
completed: 1
},
...
]
},
...
However, will this make it more difficult to update/remove existing items since they are not themselves stored as separate documents, and therefore lose things like auto-generated unique object ID's, ect? Also each user could potentially have a relatively large number of items associated with them (possibly 1000's). Is embedding large lists in parent documents like that a bad idea?
Best Answer
creating a sub collection should offer better read performance see http://docs.mongodb.org/manual/core/data-modeling/
I think it would be a good idea to add an id to each subdocument so it is easier to access it (because from your schema you may have identical items)
like:
you can use
subid = ObjectId()
to autogenerate ids, or create this in your application.I don't think there is a problem with having thousands of items in a document just remember that the maximum document size is 16 megabytes.