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