Rails: acts_as_tree和acts_as_sane_tree

Question

这是我第一次在同一模型(产品类别)中建模层次结构。

我在这个话题上找到了一个很棒的帖子。由于我使用了Rails 4& Postgres，根据本文的说法，它支持递归查询(这是我第一次听到这个词)，因此“具有递归查询的邻接列表”似乎是可行的，因为它既易于建模，又便于查询。

本文建议使用支持递归查询的树 gem。这个回购已经两年没有更新了，我不确定它是否支持Rails 4。这个项目是树 gem的一个分支，它支持Rails 4，并且维护得很好。

我应该用哪块宝石？树 gem是否支持递归查询以避免昂贵的查询？

Answer 1

如果您怀疑要使用什么gem，我总是建议您看看Ruby工具箱。它有助于评估一个gem项目是否仍处于活动状态，有多少开发人员使用此gem，以及更多。你为什么知道要这么做？不想选择不再维护的宝石。您希望使用社区使用的工具，并与主流保持一致。如果您不遵循该社区，您将遇到问题，如果您需要一个bug修复，进一步的文档，或想更新您的Rails版本。

在这种情况下，用于嵌套ActiveRecord、awesome_nested_set和祖先是很好的候选人。我不会选择递归查询实现，因为大多数数据库都不支持这一点。除非你有一个很好的理由，否则把你的应用程序绑定到特定的数据库管理系统是不值得的。

Answer 2

你考虑过祖先宝石吗？

它公开了所有标准的树结构关系(祖先、父、根、子、兄弟、后代)，所有这些关系都可以在一个SQL查询中获取。

Answer 3

在一个问题上，我同意被接受的答案

有两点我不同意:第一，仅仅因为宝石是受欢迎的，并不能使它成为正确的选择，甚至是一个好的选择。以祖先宝石为例。它已经存在很长一段时间了，很受欢迎，但是它需要你在你的桌子上添加一个特殊的列，它充满了神奇的巫毒(我对这种事情感到非常不舒服)。虽然像acts_as_recursive_tree这样的gem做的事情与祖先相同，也使用单个查询，但它只需要创建一个包含父类ID的parent_id列--可能在搜索宝石之前就已经有了。另一个例子-有一个创业板链接上传的文件到记录。我选择使用它，因为它似乎是受欢迎的选择。但当我发现它实际上是在建模许多到多个关系时，我就放弃了它，不是用一个连接表，而是通过将逗号分隔的I列表放到一个字段中(你能相信吗？)

其次，如果您选择的数据库具有像递归查询实现这样的酷特性，那么无论如何都要使用它--这也是您首先选择高级数据库的原因之一，不是吗？除非您的应用程序需要与数据库无关，否则不要害怕使用您的数据库提供的特性。为了避免将来某个时候您会想要切换到一个比您当前的功能少的数据库，避免使用数据库功能的更强大的宝石的代价当然是不值得的。

总之，我推荐的是树 --它非常容易使用，功能强大，并且可以主动维护。