请问一下类似QQ的好友关系表是怎么设计的?难道只是简单的id,userId,friendId吗?
业精于勤,荒于嬉;行成于思,毁于随。
應該還有一個分組字段
其實沒有必要把事情想得太複雜了,按照需求慢慢遞進就可以了。
這是我做關注功能的表格結構,可以參考一下。
UserRelationship: type: object properties: id: type: integer description: Id user_id: type: integer description: 用户Id target_user_id: type: integer description: 目标用户Id
非關係型資料庫
我這邊做設計的時候,是考慮了群組的功能的,所以將兩個人的好友關係也轉換為了群組
整個應該會出現三張表
一個是使用者表一個是群組表一個是使用者-群組對應關係表
透過三張表來決定的
就我所知,微博的關注就是這麼設計的
之前看過一個面試題,就是表設計問題,好友關係表如何設計,在用戶表用一個字段以逗號分隔存儲還是雙表關聯存儲的,貌似兩種都可行
這樣夠用就可以了
不過查詢起來也是個問題 redis不是很適合做這個事情嘛
或許可以再加一個是否雙向好友的標誌欄位
應該是多對多關係。 1個使用者可以有多個好友。 也可以被多個使用者加為好友。 多對多關係,在關係型資料庫裡面,一般都使用中間表來實現。 這時候中間表一般只存使用者ID和好友ID。但便於業務實現,可以在中間表加上是否驗證通過、好友分組ID、排序編號等、這個多對多中間表和一般多對多不同的地方在於,這個的關聯表是自身。也就是user表對user表的多對多關聯。
應該還有一個分組字段
其實沒有必要把事情想得太複雜了,按照需求慢慢遞進就可以了。
這是我做關注功能的表格結構,可以參考一下。
非關係型資料庫
我這邊做設計的時候,是考慮了群組的功能的,所以將兩個人的好友關係也轉換為了群組
整個應該會出現三張表
一個是使用者表
一個是群組表
一個是使用者-群組對應關係表
透過三張表來決定的
就我所知,微博的關注就是這麼設計的
之前看過一個面試題,就是表設計問題,好友關係表如何設計,在用戶表用一個字段以逗號分隔存儲還是雙表關聯存儲的,貌似兩種都可行
這樣夠用就可以了
不過查詢起來也是個問題 redis不是很適合做這個事情嘛
或許可以再加一個是否雙向好友的標誌欄位
應該是多對多關係。
1個使用者可以有多個好友。
也可以被多個使用者加為好友。
多對多關係,在關係型資料庫裡面,一般都使用中間表來實現。
這時候中間表一般只存使用者ID和好友ID。但便於業務實現,可以在中間表加上是否驗證通過、好友分組ID、排序編號等、
這個多對多中間表和一般多對多不同的地方在於,這個的關聯表是自身。也就是user表對user表的多對多關聯。