我需要做一個朋友的系統

專家mysql的意見，我需要一些幫助設計一個朋友系統我需要做一個朋友的系統

MySQL表：
friends_名單
- AUTO_ ID
- friend_ ID
- 用戶_ ID
- approved_狀態

選項1 =每次用戶添加一個用戶有2項添加到數據庫中，我們才能得到有這樣的朋友

SELECT user_id FROM `friends_list` WHERE friend_id='$userId' and approved_status='yes'

選項2 =我們添加添加1項爲每一位朋友，然後讓好友列表這樣

SELECT friend_id AS FriendId FROM `friends_list` WHERE user_id='$userId' and approved_status='yes' 
UNION 
SELECT user_id as FriendId FROM `friends_list` WHERE friend_id='$userId' and approved_status='yes'

2種方法爲在如MySpace，Facebook的網站有朋友以上，所有其他網站都會這樣做，以上兩種方法中的哪一種會是最佳性能？

第一種方法使行數增加一倍，例如一個擁有200萬個朋友行的網站只有100萬行第二種方法。

然而，聯合方法意味着有2個查詢正在進行，所以2個查詢在一百萬行表而不是1？

UPDATE

我只是跑在60000樓的朋友一些測試和這裏的結果，是的表進行索引。

選項1每個朋友有2個條目;
0.0007秒

選項2，每使用UNION朋友1項選擇
0.3100秒

來源

2009-08-10 JasonDavis

選項1.
請在加好友儘可能多的工作越好。與選擇所有朋友相比，添加某人非常罕見。每次您呈現網頁時（在社交網站上），可能都會做某件事。

來源

2009-08-10 12:44:44 Nifle

是選擇朋友快是最重要的 – JasonDavis 2009-08-10 13:05:16

如果您在user_id和friend_id上建立索引，那麼這兩個語句應該在時間上相同 - 儘管如此 - 儘管如此，DB的結果可能會令人驚訝。雖然UNION被數據庫看到，但它可以用它來優化查詢。

友誼是否永遠相互擁有相同的審批地位？如果是這樣，我會選擇第二個。如果它可以單向或單獨批准，那麼你需要第一個，對吧？

來源

2009-08-10 12:49:42

基本上user1向user2發送一個好友請求，所以這個條目被標記爲未被批准，一旦user2批准它被標記爲批准，如果user2拒絕該請求，則該條目將被刪除。如果它被批准並且他們中的任何一個決定不再成爲朋友，那麼他們將刪除該記錄。我不確定第一種方法是否需要這個或不是，我有時會有點困惑，但我聽起來像任何方法可能會工作，也許 – JasonDavis 2009-08-10 12:54:45

我應該補充說，還有一個頁面來顯示所有待處理的朋友請求，意思是從其他用戶發送給您的，您可以批准或拒絕/刪除該記錄，然後顯示您發送給其他用戶的好友請求的另一個頁面，它會顯示您發送給用戶的請求，但不批准或拒絕您但AKA等待朋友請求頁面 – JasonDavis 2009-08-10 12:56:27

我測試了兩種方式，UNION似乎慢得多，我在我的帖子上面發佈了結果 – JasonDavis 2009-08-10 13:05:41

-1

這種問題的答案往往取決於使用模式。在你最常見的情況下：增加新的友誼關係或查詢友誼關係？

您還需要考慮未來的可用性，otehr使用的數據可能有哪些。

我的猜測是該選項是一個更清晰的數據模型，用於表示您正在嘗試的內容。它看起來像允許在諸如不對稱關係和朋友的朋友之類的方向上進行擴展。我認爲這種選擇在未來將證明是不健康的。

來源

2009-08-10 12:50:42 djna

您正在使用哪個dbms？執行聯合查詢時，MySQL總是使用額外的臨時表。創建這些臨時表會爲查詢創建一些開銷，這可能是您的聯合查詢比第一個查詢慢的原因。

你有沒有想過分開朋友和朋友的請求？這將減少朋友表的內容，您還可以從朋友請求表中刪除已接受的請求，並保留表格的大小。另一個好處是你可以在每個表格中保留較少的列，從而更容易在它們上獲得精確的調整索引。

我目前正在自己構建這個功能，聽說你在這個問題上的經驗會很有趣。

來源

2009-11-10 21:01:53

我需要做一個朋友的系統

回答

相關問題