I'm looking for some recommendations on how to structure the tags part of this data model:
Here's a simplified version of it:
- a Site has man开发者_运维知识库y Posts (relational association [references_many in mongoid speak]). A Site has a tree of tags
- a Post has an array of tags (subset of the Site's tags, order doesn't matter)
The use cases I care about are:
- Quickly saving & retrieving the Site's tags in tree form (ie to be able to display them as a tree in the UI)
- Quickly querying which of a Site's posts have a certain tag.
Without the tree structure, http://github.com/wilkerlucio/mongoid_taggable solves my usecases. I've seen some of the acts_as_tree ports for Mongoid like:
- http://github.com/benedikt/mongoid-tree
- http://github.com/saks/mongoid_acts_as_tree
- http://github.com/ticktricktrack/mongoid_tree
They all seem to take a relational approach, as opposed to embedded, to storing the hierarchy, which would mean that both of the use cases above would be slow (likely requiring a map/reduce).
Has anyone done anything similar, or have any advice? Ideally I'd love a Mongoid solution, but I'm happy to drop down to the Ruby driver as well.
Do you need to update the structure of the tree (i.e. move a tag to another parent)? If that is possible, the embedded approach would become difficult, and the relational/normalized approach makes more sense.
I would probably store the tags themselves in the document (embedded), but if there is any chance that I need to move tree nodes around on-line, then I'd store the hierarchy in another document. Queries need not be slow, if you first flatten the search query (according to the current tree) and then search for those tags. This approach probably does not scale to well if the flattened search query ends up having hundreds of tags in them (how tall is your tree?).
If tags cannot be moved to new parents (or only by you, during scheduled maintenance), go ahead and embed the whole hierarchy.
there are two implemented patterns of mongodb tree structure
精彩评论