有关Mongoid/MongoDB标签树的结构的建议 [英] Recommendations on structure for Mongoid/MongoDB Tree of Tags

问题描述

我正在寻找有关如何构建此数据模型的标签部分的一些建议:

I'm looking for some recommendations on how to structure the tags part of this data model:

这是它的简化版本:

• 一个站点有很多帖子(关系关联[在monongoid中是references_many]).网站上有标签树
• 帖子具有一组标签(网站标签的子集，顺序无关紧要)

我关心的用例是:

1. 快速保存&检索树状形式的网站标签(即能够在用户界面中将其显示为树状)
2. 快速查询站点的哪些帖子具有特定标签.

没有树形结构， http://github.com/wilkerlucio/mongoid_taggable 解决了我的用例.我已经看到了Mongoid的一些acts_as_tree端口，例如:

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

• 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).

有人做过类似的事情，或有什么建议吗?理想情况下，我会喜欢Mongoid解决方案，但也很高兴也可以使用Ruby驱动程序.

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.

这篇关于有关Mongoid/MongoDB标签树的结构的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！