現在實現了點讚功能，就像樓上所說的這樣，這是經典的資料庫設計中處理多對多關係的方式。這樣的記錄數會特別多，每乙個使用者讚過的每一條微博都會有一條記錄，如果真的像新博微博業務量那麼大的話，就要考慮做分庫分表（即sharding）了。這種方案就複雜多了，我也沒做過。你再根據你的業務情況考慮一下吧。主要涉及了兩個表，
乙個是文章或部落格儲存點讚的數量，另乙個是使用者點讚記錄；
現在的問題是每次點讚都會進行資料的讀寫操作（特別是寫），併發的話會導致資料庫壓力太大，請問如何解決？謝謝。
建議增加點讚表, 字段列表:
使用者id,
主題id,
點讚時間,
狀態. 0-已取消贊 1-有效贊
我現在的疑問就是：針對這個場景，如何設計資料庫？
需要分成兩個表嗎？乙個表讀比較多，乙個表寫比較多，這樣分出來是不是有好處？
冷熱資料物理儲存分開儲存的思路是對的，冷熱資料讀寫特性不同（冷資料的讀寫比例高於熱資料），分開儲存之後可以採用不同的cache策略，冷資料因為更新少可以直接同步乙份至redis這類nosql服務，業務層直接從redis讀取，減少對mysqldb的壓力；熱資料因更新較頻繁，可以根據使用者id（或者說uin）hash到多台寫服務，並先寫至寫伺服器的本地快取中，再非同步定時批量更新至mysql，減少對mysql的寫壓力。
點讚系統設計
中秋佳節，閒來無事，寫了乙個文章點讚服務，在此記錄一下 在閱讀文章時，覺得好的文章都會點贊，表示對作者的鼓勵支援，也可能最後取消點讚，有時會反覆操作。資料結構設計 點讚結構 type like structdata字段傳入其他額外資訊，客戶端自己解析出來即可，這樣該服務就可以在其他地方使用時，不需要...
資料庫設計注意點
1.設計資料庫之前 1.在物理實踐之前進行邏輯設計 在深入物理設計之前要先進行邏輯設計。隨著大量的 case 工具不斷湧現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。2.建立資料字典和 er 圖表 一定要花點時間建立 er 圖表和資料字典。其中至...
資料庫的設計關鍵點總結
一 設計資料庫的步驟 1 需求分析階段 分析客戶的業務和資料處理需求。2 概要設計階段 繪製資料庫的e r圖，用於在團隊內部設計 設計人員和客戶之間進行溝通，確認需求資訊的正確性和完整性。3 詳細設計階段 將e r圖轉換為多張表，進行邏輯分析，確認各表的主外來鍵，並應用資料庫設計的三大正規化 下面會...