关于 feed 流中的推设计，如果有分类，用户加一个订阅到一个分类，那这个订阅老的数据怎么处理的？

[makelove]

比如我要做一个微博，用户建了一个分类，并把一些订阅人添加到里面，那这些人的老数据是不是要全部插入这个分类中？不然用户点这个新建的分类岂不是一片空白了？明明有订阅的。

如果是要插入，那这个人如果是个话唠有很多旧推，那不是给一个订阅归类都要添加 /删除海量数据？这性能不太好吧？

看了一些 feed 流文章，似乎全都没提到这点啊？是我哪里没想明白吗？

[512357301]

那如果只取最近几条呢，像你说的如果不拉历史数据会导致一片空白，那只拉取最近一段时间的 N 条数据不就可以了吗，这个时间可以固定下来，比如一个月。
如果用户想看更早的推文，那他推拽的时候再请求历史的不就行了

[makelove]

@512357301 如果引入一个设定添到分类的人只能看头一个月那是可以了，虽然有时可能用用户会造成些困扰。

> 那他推拽的时候再请求历史的不就行了
这个似乎很不好做或很复杂？比如用户请求某个时间点后的数据，怎么知道除了本来的老数据还要从有些订阅那里再取上次没取完的数据插入。

[Veneris]

关联查询不可以吗…

[512357301]

@makelove 很难吗，这不就是分页的逻辑吗，只不过这是无限分页，你可以用当前页面最早的那个时间作为查询条件，查更早之前的数据。
比如用户订阅了 3 个订阅号，每个号历史一年内都有推文，那用户首次订阅的时候，你只需要显示最近一个月这 3 个订阅号的推文就行(12.17-1.16)，按时间排序降序排列，然后把 12.17 这个时间节点存起来(存本地或者服务器都行)，如果用户拉到底部了，需要查询更早的，你只需要查(xx.xx-12.16)这段时间的数据不就行了，然后跟把 xx.xx 这个时间存起来，已备将来使用

[512357301]

@makelove 我刚才一直在描述的是取历史的推文，如果是取最新的推文，比如用户今天订阅的，默认可以看到历史一个月的推文，那他后天再来看的时候，你需要取从“12.17-12.18”的数据，很明显你需要把今天的日期或者明天的日期也存起来，作为下次查询的开始日期(存今天的日期的话，需要把日期加一天才能用，存明天的话，到时候直接用就行)

[makelove]

@512357301 你说的不对吧，比如我一个分类有 500 个订阅，我要查 1 月 10 日前的 100 条记录，具体怎么办吧？

[512357301]

@makelove 也不是不可以，好比说库里有 1000 个订阅号产生的推文(比如有 20000 个推文)，某个分类订阅了其中的 500 个订阅号，那你只需要约束日期＜ 1.10 号，订阅号 id 为这 500 个的 id ，然后按推文日期降序取前 100 条不就行了？只不过多约束个条件嘛
如果将来想在这 100 条基础上再拉历史数据或者最新数据，那就看下 100 条的头(最新的)和尾(较晚的)的推文 id 分别是多少(这个需要存下来)，想找更早的，就约束推文 id ＜结尾的 id 的记录，想找最新的，就约束推文 id ＞开头的 id 不就行了？
我之前说的方案是只约束日期，然后取这段时间内全量的数据，不考虑条数，你这个是要加个条数的限制，但逻辑是一样的，而且条数限制最终还是要对应到具体的 id 的
所以，很复杂吗？

[512357301]

@makelove 具体怎么办吧？
说实话，我特别想说，爱咋办咋办，反正不是我的需求，哈哈哈
而且你这样问会让我有一种你在剽窃我方案的错觉，虽然你可能代码经验比我丰富，当然也可能我比你丰富，哈哈哈，谁也说不准

[512357301]

@makelove 如果引入一个设定添到分类的人只能看头一个月那是可以了，虽然有时可能用会对户会造成些困扰。

这个困扰理论上压根就不应该有，因为这是产品经理的活儿，他们负责在前端交互上提前设计好，通过提示告诉用户现在展示的是最近一个月的数据，而不是让用户自己探索，也不应该由前端工程师去想是否需要提醒用户

[makelove]

@512357301 没明白你说的，不过似乎你是想直接在 sql 中过滤并排序，考虑到这个操作数据库查询效率了吗？
如果这么干我还弄什么推方式，直接简单的拉方式就好了一条大 sql 搞定。

[512357301]

@makelove 哦，sorry ，我这个确实更像是拉的逻辑，而且我觉得这个更简单