Best unofficial Apache Server developers community |
|
I am trying to understand the concept of document storage and fail to see how it would apply to some situations. For example, in the case of a CMS/blog engine there may be data in the form of:
In something such as MySQL one might have a table for each, then a join table for each set of related data. i.e. In this case, How does this translate into something like mongodb? The only way i can see this setup being structured in mongo is something like:
The output of a single bson document might look similar to:
That makes sense, but it seems like categories are going to be duplicated all over the place. With out some sort of relation, you could never be able to simply change the category name and have it reflected across all of your blog posts (?). Additionally what if these were like binary documents that took up a lot of space? Instead of duplicating the same image over and over it seems like a relationship would work better? I guess this is a pretty open question, but i was looking for anyone's input on how i should mentally take apart a problem to tell if it should fit in a db like mongo or not. And equally important is how does one structure data correctly? I have not touched on Users but it seems like EVERYTHING in this would ultimately end up as an embedded document inside of a User's collection since the User kind of starts everything. thanks a lot.
posted via StackOverflow
|
|
 
|
What's interesting about document databases is that you really need to think about how your data is going to be used. Storing the same information in multiple places (denormalization) is fine in a document database. So you're correct when you say you could have a root From my limited experience, there's not a "right" way to model a particular set of data, it's more about how that data is going to be used in the future. It IS possible to reference another documents. For example if you want a |