场景：用户对某个作品等进行留言评论， 数据库中单独一个表存储这些留言，里面包含用户的头像和昵称等信息，方案：评论表中使用 用户id, 与用户表进行关联每条评论记录直接把用户的id, 头像和昵称一起存，方便读取。疑问？原本计划方案1，可是，如果评论比较多，那就需要遍历每一条评论，取出用户id,然后在用户表查询出信息，一并返给前端，这不会很慢吗，这样的一个接口会有很对数据库进行很多次的查询。方案2:想想就觉得不太靠谱，会有很多问题，（1）空间浪费，（2）用户更新信息，会比较麻烦大家如何处理的呢，哪怕告诉我一句方案1并不慢也可以啊，打消我心中的这个疑问?。。。拜托了?
3 回答
温温酱
TA贡献1752条经验 获得超4个赞
方案1，评论比较多但是并不需要每次展示所有评论吧？每次只取一部分(比如10条)展示给用户，选择好限制条件关联用户表并不慢。
方案2，这点空间浪费没什么关系，用户更新的问题，昵称和id这类应该限制用户不能修改的吧？退一步昵称可以修改，个人觉得也并不需要实时更新到评论表里，拉取评论时再更新或者定时都行，至于头像正常情况应该存的是图片链接吧？难不成你要直接存到表里？
慕尼黑的夜晚无繁华
TA贡献1864条经验 获得超6个赞
数据不是很多的话两种随便搞，这个评论表的结构也不复杂大概id,nickname,avatar, comment.., 你可以参考下别人是哪种方式用的多，正常情况下，不存在性能问题，搞上分页，加上索引，就是干， 如果数据非常非常多又对实时性要求很高的话用第二个，连表查询肯定没有单表查询快，个人观点
富国沪深
TA贡献1790条经验 获得超9个赞
方案1，如果先取TOP N的评论，然后关联用户表的信息，一个sql联合查询的语句就能查询出结果，性能方面应该没什么问题。
方案2，明显是反模式的设计，如果评论的数据量不是很大，空间浪费不是太大问题，关键是否能接受用户数据不一致的情况，需要和产品经理确认。如果沟通后认为评论性能的问题是整个系统的关键，个人认为牺牲一些数据一致性也是可行的。
- 3 回答
- 0 关注
- 436 浏览
添加回答
举报
0/150
提交
取消