楼主是要实现多级分类的业务吗？

感觉没啥问题。就是多占点空间咯，换时间咯

类似

直接 has_many :c through: :b 不就可以用 a.c 了．

首先：c 中存 也 a 的外键 id 这个是没有 b 必要的，像楼上说的会占空间
其次：如果真的是类似于多级分类的业务其实一张表就可以搞定的也方便查询，利器

建议不存。。。否则你 a-b 的变化了 岂不是还要去改 c 的字段。感觉各种脏数据就来了。

+1

是可行，如果直接关联，可否比 joins 省较多时间；

其实我是不建议加，可是组内有个数据库比较厉害的，建议加上，说 joins 更耗时间。

@famicne 可以用这个 Benchmark 做个测试，对比下时间消耗．

先不加这种额外关联，等查 log 发现慢了之后再考虑不迟。

看你们的业务，一般还是加上好

a b c 看着好累，用实际的名称举例嘛

以country,province,city为例：
country:   has_many: provinces
province:  has_many: cities

多级关联，city对应唯一的country.

个人感觉不存，不知道这样会不会查询耗时之类的，其他有更好的方式。

第一反应是：不存。因为不干净。

第二反应是：可以存。存了能节省查询时间，空间换时间。

第三反应是：可存可不存，各有优劣，如何选择还需要看具体需求/场景。

tks

这个很好解决啊。这个问题就像：一个节点有多个话题，一个话题有多个评论。那么在评论里要不要存储节点 ID。

如果需要查询某个节点下的所有评论，那么就要存储。否则不用存。