鍍金池/ 問答/Java  數(shù)據(jù)庫/ 數(shù)據(jù)庫中評論表里關(guān)聯(lián)用戶信息性能上的疑問？

數(shù)據(jù)庫中評論表里關(guān)聯(lián)用戶信息性能上的疑問？

場景：
用戶對某個作品等進行留言評論， 數(shù)據(jù)庫中單獨一個表存儲這些留言，里面包含用戶的頭像和昵稱等信息，

方案：

  1. 評論表中使用 用戶id, 與用戶表進行關(guān)聯(lián)
  2. 每條評論記錄直接把用戶的id, 頭像和昵稱一起存，方便讀取。

疑問？
原本計劃方案1，可是，如果評論比較多，那就需要遍歷每一條評論，取出用戶id,然后在用戶表查詢出信息，一并返給前端，這不會很慢嗎，這樣的一個接口會有很對數(shù)據(jù)庫進行很多次的查詢。

方案2:想想就覺得不太靠譜，會有很多問題，（1）空間浪費，（2）用戶更新信息，會比較麻煩

大家如何處理的呢，哪怕告訴我一句方案1并不慢也可以啊，打消我心中的這個疑問

回答
編輯回答
青裙

數(shù)據(jù)不是很多的話兩種隨便搞，這個評論表的結(jié)構(gòu)也不復雜大概id,nickname,avatar, comment.., 你可以參考下別人是哪種方式用的多，正常情況下，不存在性能問題，搞上分頁，加上索引，就是干， 如果數(shù)據(jù)非常非常多又對實時性要求很高的話用第二個，連表查詢肯定沒有單表查詢快，個人觀點

2017年12月19日 14:42
編輯回答
不二心

方案1，如果先取TOP N的評論，然后關(guān)聯(lián)用戶表的信息，一個sql聯(lián)合查詢的語句就能查詢出結(jié)果，性能方面應該沒什么問題。

方案2，明顯是反模式的設計，如果評論的數(shù)據(jù)量不是很大，空間浪費不是太大問題，關(guān)鍵是否能接受用戶數(shù)據(jù)不一致的情況，需要和產(chǎn)品經(jīng)理確認。如果溝通后認為評論性能的問題是整個系統(tǒng)的關(guān)鍵，個人認為犧牲一些數(shù)據(jù)一致性也是可行的。

2017年5月1日 11:25
編輯回答
鹿惑

方案1，評論比較多但是并不需要每次展示所有評論吧？每次只取一部分(比如10條)展示給用戶，選擇好限制條件關(guān)聯(lián)用戶表并不慢。
方案2，這點空間浪費沒什么關(guān)系，用戶更新的問題，昵稱和id這類應該限制用戶不能修改的吧？退一步昵稱可以修改，個人覺得也并不需要實時更新到評論表里，拉取評論時再更新或者定時都行，至于頭像正常情況應該存的是圖片鏈接吧？難不成你要直接存到表里？

2018年7月28日 14:25