① 好友關系資料庫怎麼設計的
好友關系是雙向的：user1 > user2與 user2 > user1是重復的。目前業務很簡單就是好友關系。預想4個欄位解決：id(自增)to_user(添加用戶)
form_user(被添加用戶)relation(用戶關系)0:好友 1:拉黑但是還是想來問問看，想多了解一下相關的思路。
② 聊天系統的好友列表資料庫如何設計
對於關系資料庫，可以設一個這樣的欄位，這個欄位里存放了李四的所有好友，每個好友以「，」分隔；
對於非關系資料庫，比如說健值資料庫，可以使用一個大型的HASH表來存放，李四的所有好友以一個鏈接的方式串起來
。
比如:
linker表示鏈接
hash(李四)=linker(王五、張三、黃光、李明)
③ 微博 好友關注和推送功能的資料庫設計是怎麼實現的底層設計
我雖然沒參與過微博底層的開發，如果是我設計這個資料庫的話我會用2張表解決這個問題
第一張表 用戶信息表， 主要依靠ID主鍵識別用戶
第二張表，關系表， 關鍵col3列 前兩列 分別是 好友源 和 好友目標 ,第三列是 關系狀態
然後加了好友 只要不斷地 在第二張表加入 新行 比如
用戶A，用戶C ，好友
用戶A，用戶B ,黑名單
用戶B,用戶A, 好友
如果是QQ這類 檢索關系時候 0， 1欄位一起搜索ID 就是互為好友
微博這種 就是單向的 關注。
大概就是這樣的模型
可能的問題是用戶過多時候表2可能會非常巨大。檢索速度可能會受影響
用資源換效率的方式
還可以每個用戶一張表
④ 關於 QQ 好友資料庫設計
針對sql server資料庫來說（sql server比mysql好一些，比oracle差），如果有一個萬個用戶就一萬張表。資料庫對表數量的支持也是有限制的。
並且創建表需要有相應的級別比較高的許可權，如果每注冊一個用戶就新建一張表，用戶的許可權太高了。
再次，按照你的說法，一個人假設有1000個好友，每個表也就1000條數據，相對於資料庫來說，這個存儲量是相當小的，沒有發揮到很好的性能。sql server資料庫幾百萬萬條數據是沒問題的。
最後，這樣查詢可能會帶來方面之處，但是如果用到了存儲過程，復雜的聯合查詢等（這些都是在資料庫中常用的），你這樣做就很難完成了。
所以，為何不把這些數據集中到一張表裡面呢？
⑤ 類似QQ好友關系資料庫應該怎麼設計
同時在線人數最高時超過一億人。
不要告訴我是一對好友關系一條記錄，那樣豈不是幾十億條記錄。我想肯定不是這樣的。
------解決方案--------------------------------------------------------
userid, frientid,groupid
------解決方案--------------------------------------------------------
1、使用冗餘，每個人的好友信息都在資料庫中有存儲，就是你說的記錄一對一關系
2、數據緩存到內存，數據訪問很快
3、狀態信息修改非同步，比如一個人登陸了，他的好友不是馬上就知道，中間間隔幾秒也沒有關系
4、數據可能不放在關系資料庫中，可能使用nosql資料庫，比如mongodb,bigtable,cassandra等
5、facebook,twitter就是用類似的思想
嚴格按照範式理論就OK。
⑥ 做個好友系統 用mysql 不知道 怎麼設計資料庫 欄位有 好友ID 自己的ID 還有一個好友度 求給個思路
你好，
一個好的數據神尺庫設計，首先要保證其滿足第三範式的要求。
第三範式：每個非關鍵字列都獨立於其他非關鍵字列，並依賴於關鍵字，第三範式基數指資料庫中游鋒高不能存在傳遞函數依賴關系。
也就是說，非主鍵欄位不能有直接依賴關系或者說一個表中的列不依賴於另一個表中的非主鍵的列
根據以上思路，應該有
個人表（或用戶表），存放個人信息。
好友表，存放好友信息。
好友關系表：用戶與好友之間的關系，與那些好友ID關聯。
⑦ ASP.NET網站中好友功能怎麼做，資料庫怎麼設計
做一個表，裡面欄位 會員Id,要添加為好友的會員Id，狀態（是否對方通過審核）。
例：
如當前會員Id為1，目標會員Id為2
當加對方為好友時。寫入:
會兄隱扒員id:1,目標會員Id:2,狀態：未審。同時你可以通過站內信功能通知對方。站內信里可以加鏈接，接受或拒絕。
當對方登錄後，點擊接受，則再次寫入記錄，當前會員Id:2,目標會員：1,狀態：羨昌已審。同時更新前一條記錄。的審核狀態。
如果是攜滾拒絕則刪除對方的添加記錄。就是前面的那個。同時發站內信通知會員1.
在顯示我的好友時，調用出所有審核狀態為通過的記錄即可。
⑧ 【 資料庫設計】好友關系表該如何去設計
單獨設計一張表
兩肢慶迅個欄位 我的id （差粗local_user_id） 好友的id（remote_user_id） 編號（rela_id）可有可無歷此
⑨ 類似qq加好友的功能資料庫應該怎麼設計比較合理
建議建2個表
個人表user
（id，qq）id
為序列，qq為存渣咐梁放你自己的qq號碼，這樣你有幾個qq號簡汪就有幾列
好友表friend
（id，friend_qq，userid）id同樣為序列，為以後業務擴充做准備，friend_qq
為好友的qq號如運，userid為個人表
user
的id，
這樣2表通過userid連接，
如
select
*
from
friend
b,user
a
where
a.id=b.userid
and
a.qq=?????
就可以查出你的某個qq號對應的所有好友
⑩ 好友列表資料庫設計
3種解決方法，也談談這三種的弊端吧！
方法：
一.每創建一個用戶.自動創建一個該用戶的好友用戶表.每一行的記錄是一個好友記錄.
二.做一個Frient的表,表中有兩列,第一列UID是用戶ID,第二列FID是對應該用戶的好友
三,在用戶信息的表中,有一個欄位10000長度的varchar 里邊用','號分割各個好友的ID
弊端：
一：只適合少量的用戶論壇，如果有100萬個注冊用戶，就得有100萬張好友表，這樣當用戶一多，資料庫會很大！
二：這種方法是給用戶注冊表創建一張好友關聯表，這樣或許是這三種方法中最好的方式了吧，但是注意記得要添加索引，不然查詢起來，數據一多，會非常慢；
三、這樣在程序方面會比較麻煩，先取出來，後添加數據，再update，感覺速度會上不來...........