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

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

楊__羊羊 2018-07-18 13:38:03

場景：用戶對某個作品等進(jìn)行留言評論，數(shù)據(jù)庫中單獨一個表存儲這些留言，里面包含用戶的頭像和昵稱等信息，方案：評論表中使用用戶id, 與用戶表進(jìn)行關(guān)聯(lián)每條評論記錄直接把用戶的id, 頭像和昵稱一起存，方便讀取。疑問？原本計劃方案1，可是，如果評論比較多，那就需要遍歷每一條評論，取出用戶id,然后在用戶表查詢出信息，一并返給前端，這不會很慢嗎，這樣的一個接口會有很對數(shù)據(jù)庫進(jìn)行很多次的查詢。方案2:想想就覺得不太靠譜，會有很多問題，（1）空間浪費，（2）用戶更新信息，會比較麻煩大家如何處理的呢，哪怕告訴我一句方案1并不慢也可以啊，打消我心中的這個疑問?。。。拜托了?

查看完整描述

3 回答

溫溫醬

TA貢獻(xiàn)1752條經(jīng)驗獲得超4個贊

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

反對回復(fù) 2018-07-18

慕尼黑的夜晚無繁華

TA貢獻(xiàn)1864條經(jīng)驗獲得超6個贊

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

反對回復(fù) 2018-07-18

富國滬深

TA貢獻(xiàn)1790條經(jīng)驗獲得超9個贊

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

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

反對回復(fù) 2018-07-18