awesome_nested_set 就可以，但 100 万级有点儿崩。

都百万级了还为啥要用 Rails？

推荐使用 closure_tree, 我们之前也有类似需求。节点用多态指向你的 Folder / Article / Report

awesome_nested_set

如果都不符合要求，建议自己重复造一个轮子。 能具体解释一下，为啥这些 gem 不符合要求吗？

之前做过一个类似的项目，用的 jquery 的插件 zTree ，树形节点太多，肯定不能一次加载，异步加载

#4 楼 @gonglexin 其实了解了 closure_tree 跟其他 gem 的实现区别后，我依然比较喜欢 ancestry 和 awesome_nested_set . closure_tree 可能假设树形结构的层次会很深，然而一般情况下并不会那么深。再者存储那么深的树形层次感觉也很复杂，越复杂的实现就越难 evolve http://www.hilman.io/blog/2015/09/comparing-ancestry-and-closure_tree/

用 ancestry 的路过，很好用

ancestry 就够了，如果是 pg 的话还可以在基础上优化一下，比如用 ltree 或 array 存储和索引 path

这里有一个对比：https://evilmartians.com/chronicles/postgresql-and-rails-sitting-in-a-tree

awesome nest set 是最差的。

#10 楼 @hooopo 我最喜欢看你的分享

awesome_nested_set 每次调整节点会把子级全部更新一遍

但在明显量少的场景很好用

早上本来想回的，访问 ruby-china 一直有问题 我另外开了个帖子反馈，https://ruby-china.org/topics/32167 @huacnlee

@chucai @novtopro @hooopo @huacnlee

需求描述可能有点问题，我修改了一下题目，应该是“如何实现一个层级有限的，支持精确插入 / 修改的树形目录？ ”

一开始的选择也是 ancestry ,但需求上要求能够精确插入并记录每一个节点的位置，看了下文档，貌似 ancestry 并不好实现，因为看文档 ancestry 只记录层级，并不记录 position

“◾可以移动某一个 node 插入到 tree 中特定的一个位置，比如将 Report_id3 插入到 Article_id3 和 Report_id1 之间....”

“◾移动某个 Folder 的时候，子级的 Article / Report 全部跟随移动”

现在需求可以做一个妥协，就是一共最多三级，Project 一定是第一级，Folder 一定是第二级，然后 Article 和 Report 必须在某一 Folder 下，这样的话，那种方案又更合适呢？ 我感觉是不是都不用使用 tree 的解决方案，使用一个 sort 相关的方案就可以了...

另外，我设想的“百万级”数据是这样的：一万个 Project，每个 Project 下有 100 个节点，然后每个 Project 之间互无关联，这样的话，awesome_nested_set 的性能还会有问题不？

找资料的时候找到一个挺好的几种递归数据方案的对比文章，推荐一下给其它有需要的同学 http://www.gmarik.info/blog/2012/recursive-data-structures-with-rails/

另外....这个编辑器的换行必须是一个段落么？不能挨着换行？

我现在初步构想是两个方案：

A. 是建一个多态的 MENU 类，PROJECT，FOLDER，ARTICLE，REPORT 都关联这个 MENU 类，然后用 awesome_nested_set

B. 是在 PROJECT 加一个 MENU 字段，存一个树形结构的 FOLDER，ARTICLE，REPORT 的 JSON 结构，每次前端修改之后，由前端将整个 MENU 的 JSON 结构发给后台存起来

@gonglexin glexin

可否简单介绍一下你的方案？能实现精确插入么？

无论 projectX 是否有关系，在 awesome_nested_set 眼里就是一颗二叉树，只要增加一个节点都会触发两段 sql:

update tree set lft=lft+2 where lft>n
update tree set rgt=rgt+2 where rgt>n

所以，即使你在 project1 里面加一个 article，后面无限多个 projectX，folderX... 都需要 update，这个 gem 只适用于极少改动的小规模数据表，数据一多就 GG 了

@saiga project 和 project 之间是独立的，不过你说的意思我明白了，意思是，假设这个 project 下面有 100 个 node，然后如果我将第 10 个 node 移到了第 1 位，那么会触发将近 100 条 SQL 查询？

#17 楼 @Insub 你可以参考一下这篇 文章，不过我不建议你在这个 gem 上面浪费时间了。。

@saiga 感谢

但问题是现在不用 awesome_nested_set 的话，其它 GEM 无法实现“移动或插入某节点到精确位置”这个需求，这个需求也没法砍，纠结

#15 楼 @Insub 我们之前的做法是增加了一个 position 字段，每次插入新的节点或者移动位置的时候都会计算出一个合理的 position 出来。以下代码仅供参考：

module Positionable
  extend ActiveSupport::Concern

  DEFAULT_POSITION = 65536
  DEFAULT_POSITION_STEP = 128

  included do
    def update_position(params)
      if params[:parent_id].present? && params[:parent_type].present?
        return init_position
      end
      if params[:previous_id].present? && params[:previous_type].present?
        return reposition(params[:previous_id], params[:previous_type])
      end
    end

    def init_position
      a = sibling_activities.minimum(:position)
      b = sibling_wbs_elements.minimum(:position)

      min_position = [a, b].compact.min
      position = min_position ? min_position/2 : DEFAULT_POSITION

      update(position: position)
    end

    def reposition(previous_id, previous_type)
      previous_position =
        case previous_type
        when WbsElement::TYPE
          WbsElement.find(previous_id).position
        when Activity::TYPE
          Activity.find(previous_id).position
        end

      update(position: new_position(previous_position)) if previous_position.present?
    end

    def new_position(position)
      wbs_element_positions = sibling_wbs_elements.pluck(:position)
      activity_positions = sibling_activities.pluck(:position)

      positions = wbs_element_positions.concat(activity_positions).sort
      next_position = positions.bsearch { |p| p > position }

      next_position ? (position + next_position)/2 : position + DEFAULT_POSITION_STEP
    end
  end

end

因为我们当初实现这颗树的时候挂的是两种不同类型的 model, 所以代码优点复杂，实际上使用多态用一种 model 来表示你的节点 ( Project, Folder, Article) 会要简单很多。 另外，单纯的往树上特定位置增加节点，这些 gem 都很方便吧。我们之所以要计算 position 是因为这个树会需要频繁调整，任意一个节点和子节点都可以调整到任意位置，同时又有严格的顺序要求。closure_tree 的好处是树形关系是由 gem 维护在另外的表中。移动位置不会造成大量 SQL。

@gonglexin

我们的需求正好跟你们是一样的，Project 下挂的 Article 和 Report,Folder 实际上是一个用户自定义的 menu 目录，用户完全有可能频繁调整，而且“任意一个节点和子节点都可以调整到任意位置，同时又有严格的顺序要求”

我好好学习一下，谢谢！

ancestry 不能 includes 和 eager_load，会多很多 n+1 查询的。。closure_tree 可以把 grandparent 之类的实现成真正的关联，用起来方便很多