相似于论坛的发帖和回复功能,现在设计两张表,帖子表和评论表。
帖子表有帖子的标题,发帖人,帖子内容,发帖时间等等字段。评论表通过外键与帖子表关联,属于多对一关系。
现在的问题是查询出帖子列表,要显示评论数。本人的想法是给帖子表增加一个评论次数字段,每评论一次进行+1操作。
但是设计好提交上去,项目经理把本人的评论次数字段删去了。这样本人查询帖子列表的时候在显示评论次数的时候,每一条都需要在评论表里面统计一下评论数,这样当然非常耗时。
问一下,评论次数字段是不是真是多余的?有什么好的方法代替吗?
ps:项目经理的想法貌似就是每一次都去评论表里统计一下评论次数,也没什么好的解决方案。
帖子表有帖子的标题,发帖人,帖子内容,发帖时间等等字段。评论表通过外键与帖子表关联,属于多对一关系。
现在的问题是查询出帖子列表,要显示评论数。本人的想法是给帖子表增加一个评论次数字段,每评论一次进行+1操作。
但是设计好提交上去,项目经理把本人的评论次数字段删去了。这样本人查询帖子列表的时候在显示评论次数的时候,每一条都需要在评论表里面统计一下评论数,这样当然非常耗时。
问一下,评论次数字段是不是真是多余的?有什么好的方法代替吗?
ps:项目经理的想法貌似就是每一次都去评论表里统计一下评论次数,也没什么好的解决方案。
解决方案
5
你去问问为什么给你删掉,假如你能说出有利于项目维护和效率的原因,说服他更好
50
其实也没有多大的差异
加 评论数 列
假如帖子列表有缓存的话,处理起来就很麻烦
假如不缓存,那也是用视图做帖子列表的查询,多一列 count 不会有性能影响
其实是你没有充分发挥数据库的能力,经理的做法是对的
每个评论发布(删除)时都要去修改帖子表,代价也是不小的,还容易产生共享冲突
加 评论数 列
假如帖子列表有缓存的话,处理起来就很麻烦
假如不缓存,那也是用视图做帖子列表的查询,多一列 count 不会有性能影响
其实是你没有充分发挥数据库的能力,经理的做法是对的
每个评论发布(删除)时都要去修改帖子表,代价也是不小的,还容易产生共享冲突
10
评论次数字段确实是多余的,原因是这个字段的值会随时变化,你在页面后台代码中得到List<Replay>评论列表的时候,直接通过List<Reply>.Count就得到评论次数了,没必要专门弄个字段存放。
20
在表里加的这个字段,怎么说呢,有点儿不太符合数据库范式的规范。
原因是你没办法保证:评论表中评论的总条数永远和你帖子表中的数据是一致的。
根据你的需求,你可以把评论表中的外键作为索引,这样就解决了你说的搜索速度的问题了。搜索一次索引应该用不了多少时间~~
原因是你没办法保证:评论表中评论的总条数永远和你帖子表中的数据是一致的。
根据你的需求,你可以把评论表中的外键作为索引,这样就解决了你说的搜索速度的问题了。搜索一次索引应该用不了多少时间~~
10
猴办法。
用视图定义帖子列表和评论数。
通过帖子ID获取评论列表的时候,返回准确的[分页数、总评论数、页码、当前页评论数据]就OK了。
5
的确使用视图倒是一个办法