一個SNS資料庫表設計的問題

遇到一個資料庫設計的問題，比如有一個SNS的系統，資料庫中如何表示使用者關係，例如使用者和使用者之間的 “關注”和 “被關注”，現在有兩種方案：

 

1. 設計一個使用者關係表，欄位都是使用者ID

2. 使用者表加2個欄位表示他關注的使用者ID，例如“1,3,4,8,10”，和他被關注的使用者ID，例如“13，33,53,23,23”

 

兩種方案比較：

 

1. 方案1缺點比較多，一個是外部索引鍵關聯的效率，還有一個是使用者數量增加，這張表將迅速膨脹，即使有緩衝也不是特別的高效

2. 方案2比較高效，但如果這個使用者關注的使用者特別多的話可能達到varchar(MAX)，需要text類型，解決辦法是限制最大關注數量，例如1000個。

 

總之，對大資料庫的系統效能要盡量解耦，而且有利於緩衝的使用。