2010-06-21 99 views
2

我有一張用戶表和一張問題表。問題表將包含代表問題或答案的「問題」,「答案」和「評論」的記錄。我想爲每個用戶創建一個儀表板,以便可以查看與問題和答案相關的活動。例如,如果用戶A創建問題,用戶B回答答案,並且用戶C對用戶B的答案發表評論,則用戶A和B能夠在他們的儀表板中看到所有活動。創建飼料牆

這與Facebook主頁的工作方式類似,如果我放置視頻,我可以在視頻上看到人們的評論。

任何人都可以提出一個簡單的方法來建模在數據庫中嗎?

+1

你有沒有試圖自己建模呢?你更有可能得到建設性的答案,如果你要求幫助解決某個具體問題,而不是要求一羣陌生人爲你設計你的系統...... – 2010-06-21 15:02:48

回答

2

我相信Facebook等。人。通過擁有一個單獨的通用「更新」記錄數據庫來處理這個問題,該記錄對所採取的行動有一個簡短的描述。每當有人在網站上顯示應該在Wall中顯示的操作時,還會在更新數據庫中插入一條記錄。

+0

我嘗試了一些與你的建議非常相似的建議一張更新表。每行都與用戶(其行爲導致在更新表中創建記錄的人)以及操作的描述相關聯。當我想查找由我關注的人所採取的操作時,這很有效,因爲我可以通過他們的ID進行查詢。但是我無法找到一種乾淨的方式來檢索用戶可能採取的相關操作,我不遵循這些操作。我試圖儘可能保持簡單,以避免與其他表連接或執行多個查詢。任何想法將有助於:) – Roman 2010-06-21 14:53:47

0

好的,這裏是你可以嘗試的..你不能在同一個表中混淆問題,答案和他們的意見。一個問題可以有很多答案和不同的答案可以有不同的評論。將它們全部保存在同一個表中將會非常混亂並且不被推薦(違反RDBMS的規則)。爲問題製作三個單獨的表格,一個用於答案,另一個用於評論。根據主鍵和外鍵定義它們之間的關係。因此,在任何時候問題表中,您都有所有用戶提出的問題。答案表中將發佈與該特定問題相對應的所有答案,評論表將對相應答案進行評論。在所有表格中維護適當的支持列,您可以輕鬆管理您想要的內容。在任何時間點,您都可以通過加入問答表查看與特定問題相關的所有答案,您也可以通過加入答案和評論表來查看對特定答案所做的所有評論。

希望這給出你一個想法..

+0

我知道教科書的模式設計技術,但是性能一直是一個嚴肅的考慮因素。使用我目前的系統,我可以使用單個無連接查詢列出問題及其答案和評論。國際海事組織從傳統的模式設計角度來看,您的建議很好,但在現實生活中,有時像我描述的那樣優化會帶來巨大的收益。 – Roman 2010-06-21 15:08:08

+0

是真實的,但管理在一張桌子將完美的測試數據..但什麼時候數據的頻率是相當高的......這一切都取決於你的數據分析頻率.. – 2010-06-21 15:27:39

0

如果你要使用一個表,你可能想嘗試這樣的事情。

表{ ID, PARENTID, 用戶名, 類型, 文本, PostDtm }

這給你一個表中的基本樹結構。

折衷是你可能有更復雜的查詢,並且可能有更多的查詢需要達到你想要的。

確保您至少在ID列上有索引。

我還不確定您需要多少性能。像Facebook這樣的網站不得不考慮比表級優化。對於大多數網站,可以比這個模型更高效地查詢教科書關係模型。你的績效目標是什麼?

+0

那麼,要擊敗Facebook的流量你必須真的很大,更好。我不是在談論那種流量,但我正在考慮高於一般網站的流量。 「對於大多數網站來說,教科書關係模型可以比這個模型更有效地被查詢。」我不確定你是如何設想的,而且我可能是錯的,但我有強烈的感覺,認爲加入操作比在一張桌子上進行基本查詢更重要。無論哪種方式,我測試了這個模型,似乎過去工作得很好。 – Roman 2010-06-21 16:51:42

0

enter code here @Am,我的想法是咬住子彈,如果使用MySQL,則使用關係或移動到不同類型的數據庫,如果你想完全擺脫關係表。您希望RDB模型的非典型「清潔」實現。對於RDB,我建議你使用四個表格:用戶,user_map,問題,回覆。響應是分類的(例如,對於問題或答案),所以跟蹤哪種類型,它是任何表中唯一的外鍵是question.id和user.id的地方。

Users: id, name 
User_map (can be used with Questions and/or Responses to join the data): u_id, q_id 
Questions: id, text_value 
Responses: id, q_id, text_value, category 

您是否真的認定關係是您需要優化或正在分析的東西?如果您需要遠離基於關係的數據庫,那麼我會建議您研究爲其構建的技術。

+0

當所有問題,答案和評論都是基本相同的東西時,創建額外的表格沒有任何優勢。我在這裏看到很多答案,告訴我我必須打破我的桌子。我的問題與一桌和三桌無關。除了@ceejayoz,每個人都在暗示的是101 DB設計,即使我分解了我目前的設計,並且做了一些事情,因爲您建議我的原始問題不會得到回答!我也知道漂亮的設計是什麼樣子,但我真的很想學習一種優化的飼料牆的方法。 – Roman 2010-06-21 19:25:33