Well, you can structure it both ways. You can specify IDs, and perform extra queries, or you can "inline" the data, duplicating it across the hierarchy, but saving yourself extra queries.
Thanks for the info. Can you elaborate a bit? I guess I'm asking more which is the "right" way to do it most of the time. You can just json all your data into a giant mysql table, but that's usually not the preferred way to use a relational database. So what's the preferred way to use a document store?
The preferred way is to place a tags array in the post document, and also create an index across this array (allowing efficient lookup by tag). There's actually a specific documentation page for this usage: http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mong...
the shortcut to think about it when designing a doc-based schema is as follows: what would be a one-to-one or one-to-many relationship in a traditional RDBMS would be embedded data in the document in a doc based store. What would be a many-to-many relationship would be stored as a separate document and referenced with a foreign key.
Comments
Well, you can structure it both ways. You can specify IDs, and perform extra queries, or you can "inline" the data, duplicating it across the hierarchy, but saving yourself extra queries.
It all depends on your use case.
duplicating it across the hierarchy
Do the data stores do de-duplication internally to make this less expensive storage-wise?
Thanks for the info. Can you elaborate a bit? I guess I'm asking more which is the "right" way to do it most of the time. You can just json all your data into a giant mysql table, but that's usually not the preferred way to use a relational database. So what's the preferred way to use a document store?
The preferred way is to place a tags array in the post document, and also create an index across this array (allowing efficient lookup by tag). There's actually a specific documentation page for this usage: http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mong...
Cool...thank you very much!
the shortcut to think about it when designing a doc-based schema is as follows: what would be a one-to-one or one-to-many relationship in a traditional RDBMS would be embedded data in the document in a doc based store. What would be a many-to-many relationship would be stored as a separate document and referenced with a foreign key.