[英]Friends table for a social networking site
我一直在社交網站上工作。 這里用戶請求另一個用戶成為他的朋友(朋友請求)。 我想到了一張看起來像'朋友'的桌子
Table Name: Friends
Coloumns :
User1 - Int - FK
User2 - Int - FK
Request - Enum('0','1')
Time - DateTime
PK - (User1, User2)
在請求字段中,當User1向User2發出請求時存儲“0”,並且當User2批准該請求時存儲“1”。
當我想要檢索用戶的所有朋友時,問題就出現了。 我每次都要檢查Request字段是'0'還是'1'。 還有另一種方法嗎? 如果我有另一個表存儲朋友請求的所有細節,這樣會更好嗎?
在評論中,您基本上聲明已建立的友誼(與請求相對)在您的設置中始終是對稱的。 在這種情況下,您基本上有兩個選項:您可以將它存儲在兩行中,也可以通過匹配任一列來選擇它。 前者將產生更簡單的查詢,但后者將確保對稱性是數據庫結構中固有的,並且將避免存儲重復數據。 所以我會選擇后者,即某種形式的WHERE (User1 = XX or User2 = XX )
。 查詢可能需要兩倍的時間,因為只有一列的查詢會占用相同數量的行 ,但由於行數只是其他存儲方案的一半,因此性能方面的凈影響可以忽略不計。
您是否需要單獨的表來處理請求或建立友誼取決於這兩者在相關數據和應用程序中的控制流方面的相似程度。 因此,例如,如果您想向用戶顯示單個列表,該列表既顯示了已建立的友誼,也顯示了未決請求,可能使用不同顏色或其他任何顏色,但在同一列表中,則在數據庫中擁有單個表將更多不合適。 另一方面,如果你主要是分別處理請求和友誼,那么擁有兩個表會更自然。 如果在某個時候,你決定一個freindship需要像share_calendar
這樣的屬性,而一個請求需要像confirmation_key
這樣的屬性,那么你最好使用不同的表。
如果您決定將其作為單個表,我會建議枚舉的更多描述性值,例如調用列status
以及requested
和established
的值。 舉個例子,我乍一看將request = 1
的值解釋為“這只是一個請求,而不是一個已建立的freindship”,正好與你所關聯的意思相反。 當不同的人需要維護代碼時,這種模糊性可能導致錯誤。 幾年之后,你就會成為一個與你現在不同的人,即使你自己也可能會錯誤地解釋你的舊代碼。 所以在那里描述一下。
還有一點需要注意:您可能總是使用視圖來調整數據庫對查詢的顯示方式。 例如,您可以創建一個視圖
CREATE VIEW SymmetricEstablishedFriends AS
SELECT User1 AS Me, User2 AS Friend, Time
FROM Friends
WHERE Status = 'established'
UNION
SELECT User2 AS Me, User1 AS Friend, Time
FROM Friends
WHERE Status = 'established'
這會將數據限制為已建立的友誼,並將為您提供對稱化的功能。 在查詢中使用此類視圖,可以避免在每個查詢中處理表結構的所有詳細信息。 如果你改變了這些細節,那么改變的地方就會減少。
我會將您的數據分解為requests
和friendships
。 request
獲得批准后,將其轉換為friendship
。 它們實際上是兩個不同的對象,應該這樣對待。
Requests ::
requesting_user_id : int()
requested_user_id : int()
date_requested : datetime()
status_id : int()
Statuses ::
(Active, Declined, Accepted, Ignored)
Friendships ::
friendship_id : int()
user_id : int()
friend_id : int()
也許刪除請求,如果它被拒絕,或者有一個列(以防止人們反復請求相同用戶的友誼)。 您必須將請求轉換為兩個友誼(每個方向一個)才能輕松編制索引
SELECT friend_id FROM friendships WHERE user_id = ?
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.