84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
一直以來都有這個疑問一張文章表,文章有點讚、瀏覽記錄,評論,都是三個獨立的表,查詢文章列表數據時需要展示這三個數量。
兩種方案:
在文章表裡增加三個數量字段,每次被點讚(取消點讚)/評論(刪除評論)/瀏覽,都去更新這個字段,這樣未免效率過低了,尤其是瀏覽量每次都要更新,而且冗餘了字段
每次去關聯查詢總數,這樣速度太慢。 如果放到快取/搜尋引擎裡,那還需要每次都去更新嗎,這樣也太浪費了
當評論表的數量增長到一定程度時,增加冗餘欄位是有必要的。雖然多了幾個冗餘字段要維護,但對於效能的提升很明顯,畢竟沒人會希望資料庫被壓垮的吧?
另外,按讚數、評論數、閱讀數這些不是實時性要求很高的數據,所以不需要每次點讚(取消點讚)/評論(刪除評論)/瀏覽都去更新這個字段,你可以寫個定時腳本,每半小時或一小時去更新那些冗餘字段就可以了
分錶的設計是沒錯的,當你考慮到資料量增大,一張很重的表並不好用。如果考慮到按讚等以後還有其他額外信息,這樣做就更有必要了。
推薦做緩存,並且只即時更新緩存,具體持久化可以定時跑。
當評論表的數量增長到一定程度時,增加冗餘欄位是有必要的。雖然多了幾個冗餘字段要維護,但對於效能的提升很明顯,畢竟沒人會希望資料庫被壓垮的吧?
另外,按讚數、評論數、閱讀數這些不是實時性要求很高的數據,所以不需要每次點讚(取消點讚)/評論(刪除評論)/瀏覽都去更新這個字段,你可以寫個定時腳本,每半小時或一小時去更新那些冗餘字段就可以了
分錶的設計是沒錯的,當你考慮到資料量增大,一張很重的表並不好用。如果考慮到按讚等以後還有其他額外信息,這樣做就更有必要了。
推薦做緩存,並且只即時更新緩存,具體持久化可以定時跑。