2009-09-02 50 views
5

我有一個相當複雜的社區網站(在php/mysql中)有一些「東西」,註冊用戶可以「觀看」。如何創建「Watch」系統?尋找最佳實踐

「東西」是:帖子,評論,事件更新,用戶狀態的變化等的「事情」至少有10種不同類型供選擇,用戶可以觀看其他用戶的「東西」(認爲Facebook)

「觀看」表示:用戶可以觀看任何「事物」,並查看所有類型的「事物」中每個「事物」的所有更新/添加的提要。

我建立了一個類似的應用程序少得多的「東西」,可以觀看和我的設置基本上是這樣的:

「手錶」表中的字段:ID,用戶id,的itemId [ID在國外表] ,itemClass [外部表的引用ID]

用戶可以添加'手錶',在'手錶'表中創建一條記錄,然後我們將查詢該表(並緩存),以便他們瀏覽我們可以注意到(在用戶界面上)他們是否已經在觀看特定的物品,他們可以查看並管理他們正在觀看的系統中的所有物品。很簡單。所以,(在這個冗長的介紹之後),我們正在構建的這個社區網站將需要更大幅度地擴展。成千上萬的用戶將會觀看數百件「事物」,我們不僅需要輪詢「手錶」表本身,還要查詢每個外表的聯接表以獲取詳細信息以填充每個用戶的觀看饋送。

如果您對我的意思感到困惑,請考慮您在Facebook主頁上提供的Facebook好友Feed。如何在沒有運行大量查詢的情況下進行更新?

+0

我一直就同一問題進行至少6個月,我已經找到一個「好」的解決方案尚未 – JasonDavis

+0

更好地描述什麼可以觀看沒有取得進展。你說「事情」:帖子,評論等。有人觀看所有帖子,或只有某些帖子,所有評論或只有某些評論。如何儲存此腕錶信息至關重要,但我需要在提出建議之前更好地理解它。 –

+0

@KM - 好問題。以下是簡單的細分(我希望):如果您觀看用戶,您會收到所有帖子,評論,圖片,狀態更改以及該用戶狀態更改的評論的通知。如果您觀看帖子或圖片,您會收到有關該帖子或圖片的所有評論的通知。如果您觀看新聞話題,您會收到該新聞話題中所有帖子的通知(不是評論)。 – phirschybar

回答

1

在可伸縮性和忽略規範化規則(您有時需要爲性能方面的原因而需要做)方面做的最好的事情是將手錶存儲在已有的表中,但是隨後還要添加一個TEXT列到以分隔的方式存儲所有觀看該項目的用戶的ID的內容表格。

當項目更新時,您可以方便地預建人員列表,以免發生額外開銷。

當用戶希望看到他們在看什麼,你有你的高效規範化的表。

vbulletin這樣做我認爲是爲了跟蹤誰讀了一個特定的線程。

+0

這很好。沒有想到將id與實際內容一起存儲。非常有幫助。 – phirschybar

0

當有人進行更新時,它可能會通知所有「觀察者」某些內容已發生變化,並提供查詢參考。所以當我登錄時,系統查詢我的表並發現有些「事物」進行了更新。然後它會獲取該更新並在頁面上顯示給我。這就像發佈/訂閱模式。

EDIT(包括我的評論):

每個用戶都將有一個行中與之相關的watch_table。所以我把自己作爲一名觀察員加入到我女朋友的狀態更新中,並存儲在她的用戶記錄中。然後,當她更新時,遍歷她的觀察者列表,在watch_table的每個觀察者記錄中放置一條記錄。因此,當我登錄時,我的watch_table記錄被查詢,並且我在UI中看到她的狀態已更新。

以上是使用facebook狀態更新的一些語義。

+0

這是最初看起來最吸引人的方法,但您如何存儲這些數據?我們不是通過電子郵件「通知」,而是存儲手錶活動。如果我有1000個用戶正在觀看相同的事情(可能),那麼每次更新時都必須寫入1000行。 – phirschybar

+0

每個用戶都有一個與他們關聯的watch_table。所以我把自己作爲一名觀察者加入到我女朋友的狀態更新中,並存儲在她的用戶表中。然後當她更新時,遍歷她的觀察者列表,在每個觀察者的watch_table中放置一條記錄。所以當我登錄時,我的watch_table被查詢,並且在UI中看到她的狀態已更新。 – geowa4

+0

我以編輯的方式拋出該評論。 – geowa4

2

您的投票的另一種方法是設置您的系統,以便在創建項目後記錄「觀看更新」。

的邏輯是:

  1. 後創建
  2. 在災後建立的最後一步,一個 查詢對手錶運行 表多人觀看了新 帖子
  3. 手錶發現你寫入該用戶「活動」或 觀看饋送的 條目。
+0

是的 - 與geowa4的答案相同的概念。我非常喜歡這個。但是我擔心每次進行更新時都會對數據庫進行大量寫入。 – phirschybar

+0

如果這是sl flame不馴的,但是如果我只是爲「活動」表更新一個記錄並在「觀察者」字段中用逗號分隔的用戶標識列表該怎麼辦?然後,我可以使用MySQL的FIND_IN_SET在需要時獲取相關人員。這不好嗎? – phirschybar

+0

難道你不會有大規模的寫作方式:在「事物」創建或當你輪詢項目+手錶? WRT你的find_in_set解決方案,你會遇到任何問題,這是一個選擇你自己的毒藥的情況。 –

0

每次保存時,您需要確定這是否爲「已觀看」項目並將其記錄在新表格中。你需要保存,它是什麼類型的項目,誰在觀看它等,當你需要顯示任何觀看的項目,你查詢這個快速的新表。

+0

這似乎是共識。我非常喜歡它。但現在對我來說,最大的問題是如何儲存「誰在看它」。在Mike Buckbee的回答下查看我對FIND_IN_SET的評論。思考? – phirschybar

0

您可以使用日期來跟蹤用戶有或沒有看到的內容。當用戶登錄時,他/她在某個日期/時間登錄。當用戶稍後再次登錄時,您可以針對該用戶正在「監視」的所有「事物」運行查詢,該查詢比上次登錄日期更新。這將創建讀者列表而不是每個「事物」更新。

0

就模式而言,這裏要記住的一點是經典的「聽衆」/「事件通知」/「觀察者」模式。你想鬆散地聯繫正在生成事件的人和正在傾聽他們的人,以便在添加新的偵聽器後不必修改事件生成器。

確實,發出通知「我改變了!」或「我是一個新的職位!」在對可觀察對象進行相關修改之後,並在註冊所有聽衆的表格中查找,似乎是一種很好的方法。

0

看看MSFT的SQL通知服務。雖然SQL Sver 2008不再支持,但其文檔描述了一個強大的通知引擎。您可能或不可能想要建模的東西 - 取決於您的需求。