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

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

方案：

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

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

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

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

回答

編輯回答

青裙

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

2017年12月19日 14:42

編輯回答

不二心

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

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

2017年5月1日 11:25

編輯回答

鹿惑

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

2018年7月28日 14:25