看了楼上的回复没有太大的启发。 我倾向用 @ ,但是 @ 如果看线索形式的回复内容的话很无力。 目前我认为最佳的貌似在我的印象里只有张大妈了=。= 超过三层自动折叠中间的楼层,大概是比较折中的一种做法。 不过为了防止对数据库造成压力,每次评论的时候得保存线索串的 id ,怎么存比较恰当是一个值得思考的问题。 本来我认为只要限定最多 10 个线索串 id 就行了,看到值得买的一个神回复,瞬间又没想法了,继续琢磨去。 http://haitao.smzdm.com/p/313129
branchzero
2015-10-03 03:48:53 +08:00
关于目前的博客的回复存储形式,都是加一个 parent_id 存储完事,不存线索串的所有 id ,总感觉在回复量大的情况下会对查询构成负担。 (根据 parent_id 一层层回溯肯定不靠谱,博客应该是把这个 topic_id 的的所有的回复都取出来,然后再根据结果来一层层整理,但如果有分页呢,也查出所有结果是否是多余呢?) 论坛的做法,只有一层引用,且把引用的内容给直接存到这个回复里面了。 目前看来适当的冗余,按顺序存下线索串然后根据值得买的样子做适当折叠,保留搭楼的形式,大概是最好的做法了。 先查出该页的所有回复内容,然后再把所有回复内容的下面的线索串 id 取出来,然后合并后去重然后和这页回复内容取差集,然后丢进去再查询一次,再构造楼层结构是最好的做法了。
lostvincent
2015-10-03 10:22:21 +08:00
@branchzero 这样的话还是只能解决一级回复,多级还是老样子(某文章区已经去重了,隐藏中间楼层加个展开选项就是你的形式了,大概没理解错?)如果层主是 a ,回复 a 的称做 b ,那么如果有回复 b 的 c 存在以及可能有 defg 等,除了 a-b 这部分,其他的会更加混乱吧,我最想的是把没级都理清,然而并没什么思路(捶地 orz
branchzero
2015-10-03 11:19:23 +08:00
@lostvincent 不会有问题的说,其他的并不影响吧,每个回复他对应的线索串 id 集合都是独立的,是他上面的所有层的回复的 id 集合。
第 1 页 / 共 1 页
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。