没看懂你说的。。。

简单解释下 Relation 的价值，另外你可能还会看到一个叫做 CollectionProxy 的类型（user.posts 这种类似调用会遇到），他是 Relation 的子类。

Relation 实现了 Enumerable，所以你做遍历之类的集合操作是 OK 的，另外，其实在你真正需要使用数据前，还没有进行查询呢，这种手法叫做 lazy_evolution，就是延迟计算。

想象一条查询 Post.where(author: me).page(2).per_page(10) 我的意图是获取我发表的帖子中位于第二页的，如果没有 Relation 每次调用都会返回结果集，那么就要意味着进行 SQL 查询，这里就有问题，首先明确一点，IO 的代价是极大的，SQL 查询是一个网络 IO 操作，通常是性能的瓶颈所在，其次，这个中间结果我们并不需要。那么，我们就需要一种手段，来避免这种中间过程的产生，这就是 Relation 的价值。

此外，ORM 有一种经典问题要避免，即 N+1，想象 user.posts.map { |post| post.title }，从代码上看，我需要的是每一条 post，于是就产生了 N+1 问题（查询 user 为一次查询，之后发出等同于 posts 数量的查询来获取每条 post 的数据），Relation 来持有 eager_load 的信息，保证绝大情况下避免 N+1 的情况（当然需要你来手动指出）。

另外这里引申一点，Ruby 标准库的集合操作都是不支持延迟计算的，于是会导致大量中间变量的创建，这其实隐含了性能瓶颈。